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REMARKS- General 



By the above amendment, Applicant has amended and rewritten all claims to define the 
invention more particularly and distinctly so as to overcome the rejections under 35 USC § 1 12 
and 103, and define the invention patentably over the prior art. 



The Claims Rejections Under 35 USC § 112 



The O.A. rejected claims 143, 144, 146 and 148 under 35 USC § 112, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention (i.e.: such as email or web page are indefinite). 

Applicant thanks the Examiner for pointing out this error. Claims 143, 144, 146 and 148 have 
been rewritten to delete the words "such as email or web page". Applicant respectfully submits 
that they are now in a position of allowance, which is requested. 



The Claims Rejections Under 35 USC § 103 

Claims 132-135, 141, 142, 151-163, 171, 177, 180-182, and 187-195 were rejected under USC § 
103(a) as being unpatentable over Lazaridis et al [Lazaridis, 6,219,694] in view of Shachar 
[5,923,736]. 

Applicant requests reconsideration and withdrawal of this objection for the following reasons: 

1 . Applicant submits that the O.A. has incorrectly interpreted Lazaridis and Shachar as 
being equivalent to the steps of the present invention. 
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2. Even if the interpretations were correct, combining the two references is not an obvious 
step under § 103 because: 

a. It leads to valuable new, improved, and unexpected results. 

b. There are financial incentives to create said combination in that it saves money 
over previous techniques. 

c. There are financial incentives to create said combination, in that there is a 
commercial demand for the unique capabilities that it provides. 

Commercial Success. The Applicant has proven reason #2C by reason of implementing the 
present invention and has generated considerable revenue by providing services and products 
incorporating it, as documented in a previously submitted declaration. Thus the fact that this 
combination was not depicted in prior art at the time of invention despite the financial incentives 
is prima facie evidence of its unobviousness. 

Applicant requests reconsideration and withdrawal of this Reason for the listed claims because 
the element shown in the prior art (Lazaridis and Shachar) is not an equivalent of the structure, 
material or acts disclosed in the application. The listed claims recite structure that is physically 
different from every cited reference and is unobvious under USC § 103. 



The Rejection of Claim 132 Under USC § 103 Is Overcome 

Claim 132 was rejected as unpatentable over Lazaridis in view of Shachar. The O.A. stated that 
Lazaridis discloses a method to allow a user of a local computer to access a computer file, the 
method comprising the steps of: 

(a) providing a communications network[Lazaridis, Internet 18, Fig 1]; 

(b) the server system detecting the activation by the user of a hyperlink associated with 
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the computer file; [Lazaridis, server detects event from users, col 4 lines 19-38]; 

(c) operating on a computer remote from said user an application program compatible 
with or capable of loading and operating upon the computer file, and has a graphic 
user interface [Lazaridis, the redirector software makes information appear 
transparent to the user, col 10 lines 10-20]; 

(d) opening the computer file in the application program running on the remote computer 
[Lazaridis, remote device, send text, video, audio to the target systems, col 6 lines 7- 
30; 

(e) operating a thin client of the terminal emulation type on the local computer (i.e. a 
palm computer), the thin client allowing the user to provide input to the application 
program running on the remote computer, whereby control and protection of the 
computer file is retained, while providing simple and easy access to the user via said 
server-based applications delivered via thin client [Lazaridis, palm top computer, 
seamless, transparent redirection of user-selected data items, col 6 lines 31-48], 

Physical Difference Over Lazaridis- Lazaridis's Trigger Event is Not a HyperLink 

In Para 4b of the O.A., the words of claim 132 "detecting over said communications network the 
activation by the user" is considered equivalent to Lazaridis, "server detects events from users", 
col 4 lines 19-38. 

The actual claim words are "the server system detecting the activation by the user (over said 
communications network- previous subparagraph)" of a hyperlink associated with the computer 
file". 

The cited user events are filtered by (compared to) user-defined event triggers. If the user events 
are found to be within the criteria specified by the event trigger, this causes forwarding 
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(redirecting) of email and email attachments to the user. This is not equivalent to a hyperlink 
associated with a computer file. 

Physical Difference- Lazaridis's "Makes information transparent to user" is not 
equivalent to claimed "graphic user interface" 

In Para 4c of the O.A., claim 132 para(c)-"operating on a remote computer an application 
program associated with the computer file, and has a graphic user interface ", is considered 
equivalent to Lazaridis, "the redirector software makes information appear transparent to the 
user", col 10 lines 10-20. 

The full quote from Lazaridis is "These... components are illustrative of the type of event- 
generating systems that can be configured and used with the redirector software 12, and of the 
type of repackaging systems that can be used to interface with the mobile communication device 
24 to make it appear transparent to the user." 

So in this context, "transparent to the user" is not equivalent to a GUI operating on a remote 
computer. In fact, it refers to reformatting data and transmitting it to the user so that an 
application (and GUI) on a computing device LOCAL to the user can load and display it. 

This is clearly shown by the fact that Lazaridis's remote device refers to the user's mobile 
device, such as a cell phone (Lazaridis, "mobile device 24", col 6 line 19; "the remote device", 
col 6 line 24), and not to a computer remote from the user. Sending files to an external machine 
is mentioned by Lazaridis, but examples of this external machine are display devices close to the 
user such as a fax machine or printer local to the user, or to storage devices accessible by the 
user such as video data storage or the user's voice mail storage (Lazaridis, col 6 lines 9-13). 
Operating on a remote computer an application program compatible with or capable of opening 
the computer file is not mentioned anywhere within Lazaridis. 
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Physical Difference- Lazaridis Does Not Open the Computer File In The Application 
Program Associated with the Computer File On a Computer Remote to the User 

In Para 4d of the O.A,, claim 132 para(d)- "opening the computer file in the application 
program", is considered equivalent to Lazaridis, remote device, send text, video, audio to the 
target systems, col 6 lines 7-30). 

However, the claimed application program is operating on a computer server system which is 
remote from the user, as prior claim 132 subparagraphs make clear. Lazaridis sends the data to 
the target systems which are devices LOCAL to the user. 

Physical Difference- Lazaridis Does Not Teach Operating A Thin Client of Any Type 

In Para 4e of the O.A., claim 132 para(e)- "operating a thin client of the terminal emulation type 
on the local computer (i.e. a palm computer), is considered equivalent to Lazaridis, palm top 
computer, seamless, transparent redirection of user-selected data items, col 6 lines 31-48. 

While a palm top computer is capable of operating as a dedicated terminal or a software-enabled 
terminal emulator, as is well known in the art, Lazaridis does not refer to a palm top computer 
with either of these capabilities. A palm top computer by itself is not a terminal or terminal 
emulator. It must purposefully be designed for that function or have the necessary software 
purposefully installed. The Lazaridis citation referred to by the O.A. refers to forwarding data to 
the local device (such as a palm top computer) for opening by an application running ON THE 
PALM TOP. This is completely opposite to the accepted meaning of the term "thin client", 
which refers to an application running on a device REMOTE from the user, and the interface to 
that application being delivered to the user via a separate thin client. Lazaridis teaches that the 
application which displays the file runs locally, so there is NO NEED for a thin client. 

O.A. Official Notice Refers to Specific Meaning of Thin Client Contrary to That Claimed 
and Specified. The O.A. takes an Official Notice that the thin client or diskless terminal or 
emulate terminal are interchangeable (O.A., page 4, para 1). It is true that standard usage of the 
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term thin client has two distinct meanings. One is a physical computing device which acts as a 
dedicated terminal to a remote server. The second meaning, which is the meaning as claimed, 
refers to a simple client program which relies on most of the functionality of the system being 
located on the server. 

M A term used in the claims may be given a special meaning in the description, but no 
term may be given a meaning repugnant to the usual meaning of the term." MPEP 
608.01(0); 2173.05(a). 

The applicants more specific, distinct, and non-repugnant meaning of "thin client", as described 
in the specifications, is wherein the GUI is generated or created on the server and transmitted 
and displayed to the user via the thin client, in essentially a terminal emulation mode. The major 
processing done by the thin client is to send user input (keystrokes and mouse movements) to the 
server and receive the updated GUI state from the server and display it on the user's screen. 
Examples of thin clients of this type known in the art include Citrix and Tarantella. These major 
commercial products demonstrate clearly that the applicant's definition is within the meaning of 
the art. 

Definition of Thin Client From Specifications. An excerpt from the current application's 
specifications defining "thin client" make clear the above physically different meaning of the 
term: 

"A definition of thin client as intended by this invention may be useful. This terminal 
emulation may proceed by input at the client machine being transmitted as instruction 
requests to the server. Upon execution of the instruction request at the server application 
level, the server web-enabling application may modify the GUI or other interface state of 
the remote user's data file, as returned by the "user application" running on the server, 
i.e., the application that the remote user wishes to use for manipulation of a certain data 
file. In other words, the user's input on the client machine is transmitted to the server, 
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executed on the user application running on the server, and the output of the user 
application is sent to the client machine, basically, as a "picture " of the server 's 
executable user application output. 

Because this picture is preferably changed very frequently, the experience of the client 
user is substantially the same as if the user was inputting commands to executable code 
resident on the client machine. This "picture" repeatedly sent to the client user may be 
termed the "GUI state" of the application executing on the server. The executable code 
which allows the client machine to emulate a terminal, i.e., allows the client machine to 
send instructions to the server machine, and display the GUI or other output of the client 
machine, may be considered a component of enable code, and is called commonly a 
"thin-client". If a client machine already has the terminal emulation thin client software 
installed, the enable code downloaded to the client machine may consist solely of the 
server-based application's "GUI State"." [Substitute specifications, page 9, lines 22-31, 
page 10, lines 1-8]. 

Lazaridis Does Not Specify a Hyperlink. Shachar and Goldberg Do. The Combination Is 
Unobvious Under USC § 103. As detailed above, the claimed invention is in no respect 
equivalent to Lazaridis. Even if it were, the O.A. acknowledges that Lazaridis does not explicitly 
detail "the activation by the user of a hyperlink associated with the computer file". 

However, the O.A. states that it was well known in the art that a HTML service module can 
detect the user's interaction with a hyperlink which is associated with a computer file [Shachar, 
col 13 lines 32-40]; [Goldberg, a detection of an activation of a hyperlink by the user, col 37 
lines 50-55]. The O.A. then states that "it was obvious to an ordinary skill in the art at the time 
the invention was made to incorporate the detection and activation of a hyperlink by user as 
taught by Shachar into the Lazaridis apparatus in order to utilize the server detection process. 
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Doing so would provide more capabilities than are required just for access online services 
[Shachar, col 5 lines 7-12]. 

No Suggestion to Combine. Nowhere in Lazaridis does he mention the word "hyperlink" or 
imply similar functioning. Additionally, neither Shachar nor Goldberg suggest combining a 
hyperlink with remote thin client access to a file. 

Suggested References Cannot Be Combined As Suggested. In fact, Lazaridis teaches away 
from using a hyperlink associated with a computer file. It is agreed that it would be obvious to 
one of ordinary skill to use a hyperlink as a "triggering event" as defined by Lazaridis to allow a 
user to initiate data redirection and forwarding. However, a hyperlink used in this way would 
NOT be associated with a specific file. Lazaridis's trigger events are not associated with any 
computer file; rather they are the trigger to begin redirecting or pushing subsequently received 
files (email and attachments) to the user via various devices. An example of a case where said 
event trigger is associated with no files whatsoever is that if no emails are subsequently received 
by the host system after a triggering event, the triggering event will redirect (forward) nothing. In 
fact, by definition, the triggering event cannot be associated with a particular file since it is 
generated before any email or attachment is received. 

Therefore it would not make sense to combine a hyperlink associated with a computer file with 
Lazaridis, since the suggested combination would include contradictory functions, i.e., the idea 
of forwarding specific, known data files that are not in fact known because they have not arrived 
yet. In other words, Lazaridis is "push" technology where messages and data are automatically 
forwarded to a user as they are received after a trigger event has occurred. Whereas the hyperlink 
in Claim 132 is "pull" technology, where access to a file is given when requested by the user. At 
no time does Lazaridis suggest any kind of "pull" mechanism. 

Suggested Combination is Unobvious* Even if Lazaridis was the equivalent of the steps of the 
method as claimed (not the case for the reasons detailed above), the suggested combination is 
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unobvious because it results in new, improved, unexpected, and valuable results. A few of those, 
as disclosed in the specifications, are: 

Improved Access To Applications And Files, Associating a hyperlink with an online 
application and file and giving access to said application and file via a thin-client 
delivered GUI allows the easy, simple access to remote applications and files to be 
greatly expanded over the art at the time of invention. Specifically, access to applications 
and files can easily be added to emails, web pages, or any other hyperlink-capable 
communications medium. For example, an ordinary web page can giving a user access to 
a dozen different applications, running on three different operating systems. This access 
can be done simply by pasting into the web page a few URLs. 

Improved Data Security. Lazaridis's invention does not keep data secure by keeping it 
on the server. In fact, Lazaridis teaches that raw data is transmitted to the client, possibly 
after reformatting it to make it compatible with the client. The question of data security is 
not addressed. This is in contrast to the claimed invention, where improved security is 
intrinsic to the invention because raw application data is not transmitted to the client. 
Only GUI refresh data is transmitted. A thin client as claimed keeps the applications and 
data remote from the user. 

Improved Intellectual Property Protection. Because the file and application remain 
remote from the user, many new and unexpected capabilities to protect the file become 
possible versus the alternative of downloading the file to the user. Some are: Restricting 
the time that a file can be accessed, for example restricting a test to be taken to a specific 
one-hour period. 

In addition to those cited above, many other new, valuable, and unexpected results are disclosed 
in the Applicant's specifications. 
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The Rejection of Claim 133 Is Overcome 

Claim 133 Is Dependent on Claim 132, and so meets Requirements of § 102 and § 103. 

Claim 133 is dependent upon, and incorporates all of the limitations of, claim 132. Therefore, 
since claim 132 meets the novelty and unobviousness requirements as detailed above, so also 
does claim 133. Specific reasons for the rejection of claim 133 raised by the O.A. are discussed 
next. 

Claim 133 was rejected because Shachar discloses the hyperlink contains a unique identifier (i.e.: 
html tags, URLs), and associating the unique identifier with metadata identifying the computer 
file [Shachar, database, col 1 lines 30-47]. 

Claim Previously Rewritten. Claim 133 was rewritten in amendment B to delete the 
reference to a unique identifier: The claim as rewritten now reads: 

Claim 133. The method of claim 132, wherein the hyperlink points to a network location 
or address associated with metadata identifying the computer file . 

Misinterpreted Shachar Citation. Even if the O.A. had referred to "network location" 
(new claim) instead of "unique identifier" (old claim), the Shachar citation simply refers 
to giving access to a database via the internet. It does not refer to URLs or hyperlinks or 
using a database to associate metadata with a URL. 

Associating An Identifier (Now Network Address) With Metadata Identifying the 
Computer File Is Not An Inherent Feature Of An HTML File. Even if the unique 
identifier is considered to be a URL, it does not contain and is not associated with file- 
related metadata. 

HTML Document Is Not Metadata. The HTML document pointed to by the URL may 
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have HTML tags, but the tags are not metadata. An HTML tag is not metadata because it 
is part o/the file (HTML document), not about the file. 

Definition of Metadata As Known In The Art: Metadata literally means "data about 
data", or information that describes another set of data. A common example is a library 
catalog card, which contains data about the contents and location of a book: It is data 
about the data in the book referred to by the card. Other common contents of metadata 
include the source or author of the described dataset, how it be accessed, and its 
limitations. Nearly all file systems keep metadata about files out-of-band (that is, 
separate from the file itself). Some systems keep metadata in directory entries; others in 
specialized structures like i-nodes or even in the name of a file. Metadata can range from 
simple timestamps, mode bits, and other special-purpose information, to icons and free- 
text comments. 

Physical Difference With Known Art. Combining the step of associating a URL with 
metadata which links the URL with a particular file with subsequent steps of opening the 
file in a server-based application and giving the user access to the file and application via 
thin client is novel and is an unobvious difference under § 103 because it results in 
improved and unexpected results. 

URL Is Not Metadata. From the above definition, it can be seen that metadata is data 
about a file and is normally kept in a separate location. Neither criteria is met by a URL 
pointing to a HTML document. 

Valuable, New, Improved, and Unexpected Results. Claim 133 added to Claim 132 the 
step of associating a network location or address with metadata identifying the computer 
file. This is patentable because it produces unexpected results as detailed in the 
specifications, i.e.: 
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Customized Application Interfaces. In one embodiment of the present 
invention, a utility for modifying an application's interface settings as specified 
by a particular file's metadata is provided. The ability to send someone an 
AppLink to a file or to share files online using server-based applications turns 
server-based applications into a means of communication. There is a need, 
therefore, to modify applications for their new communications role. The 
application interface which the AppLink or shared file recipient sees will 
preferably be optimized for the particular purpose that the AppLink sender or file 
sharer has in mind. According to an embodiment of the present invention, the 
ability to associate custom interface settings with each file is provided, by means 
of file metadata. Such metadata can contain the actual application interface 
settings for that file, or user-specified metadata "key words", which point to 
application settings for all files whose metadata contains those key words. 
Examples of this type of metadata might be the key words "presentation for 
customer" or "document for internal use", etc. Another user accessing the file 
through an AppLink would be limited to the application interface specified by the 
author. Multiple interface settings could apply to a single file, if it is used in 
multiple ways. Multiple interface settings could be linked to the role of the 
document at the moment, such as "being created or edited", or "being viewed by a 
customer". These settings could also depend on the identity or role of the viewer, 
such as "document creator", or "viewer". [Specifications, page 14 line 20- page 
15 line 9] 

Customized File Restrictions. ...access restrictions and application 
functionality restrictions can be created automatically based upon the file security 
level contained in the file metadata. This security level may, in turn, be tied to the 
sender's or recipient's job title or security clearance, in addition to file-specific 
criteria. Where multiple restriction criteria apply, the most restrictive choice can 
be made. For example, normally a document might have minimal restrictions, but 
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because it is being sent to a potential competitor, access is severely limited. 
[Specifications, page 19 lines 10-15] 

And 

Each file has metadata associated with it that specifies the security level of 
the file. Each user, in turn, has a specified clearance level. The file security level 
and the user clearance level interact or are compared in order to determine the 
user's access and privileges with the individual file. Applicable application 
functionality restrictions may include the following: read/write, read-only, no 
printing, no editing, no copying, or various other restriction on application 
functions as applied to the particular file. The restrictions may also be event or 
time-based, e.g., there may be a restriction that a user may access the file a certain 
number of times, view until a particular date. The access may also be based on 
the access location of a remote user, e.g. a user may only access the file from a 
certain IP address or modem phone number, or conversely, may NOT access the 
file from certain IP addresses or phone numbers. This may prevent unauthorized 
access when authentication information is compromised, or during a duress 
situation, or to prevent applications from being used in countries where export 
laws prohibit use. In addition to business applications, allowing implementing 
organizations to ensure the confidentiality of internal or client projects, the 
present invention also admits of certain military and government applications. 
For example, the present invention may be used to prevent cases of espionage, or 
the unauthorized access or downloading of files in excess of one's authority. As 
another example, documents may be securely maintained on a central server, thus 
eliminating the problem of a stolen or misplaced laptop, for example, 
compromising the security of documents on the laptop. In the healthcare arena, 
the present invention may be used to implement the patient data protections 
mandated by the HIPAA statute and regulations. Data may be viewed securely by 



Page 36 



Appn. Number 09/866.454 fRice)VU 2142 Amendment C contd. 37 of 121 



authorized users, without allowing the viewing, downloading, or further 
transmission of unauthorized patient information, thus aiding in compliance with 
regulations governing the security of individually-identifiable patient information. 
[Specifications, page 21 lines 7-29] 



Physical Differences With Accessing An HTML Document. The claimed invention 
has novel physical differences compared with activating a URL and accessing an HTML 
document. Specifically, accessing an HTML document downloads the HTML text to the 
web browser, and the web browser interprets the code and renders the document on the 
client PC. In the claimed invention, the document is not downloaded to or rendered by 
the web browser. 



The Rejection of Claim 134 Is Overcome 

Claim 134 Is Dependent on Claim 132, and so meets Requirements of § 102 and § 103. 

Claim 134 is dependent upon, and incorporates all of the limitations of, claim 132. Therefore, 
since claim 132 meets the novelty and unobviousness requirements of § 102 and § 103, so also 
does claim 134. Specific reasons for the rejection of claim 134 raised by the O.A. are discussed 
next. 



Claim 134 was rejected because the Office Action stated that Lazaridis-Shachar discloses the 
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application program is associated with the computer file after the activation of the hyperlink is 
detected as inherent feature of HTML file (underlining added). 

A URL's Access Protocol Is Specified Before URL Activation, Not After. A URL 

intrinsically contains the access protocol before activation of the hyperlink, whereas in 
the claimed invention, the application program can be selected after hyperlink activation, 
perhaps taking into account further input from the recipient, such as identifying data. 

A URL Access Protocol Is Not An Application Program. A URL's access protocol 1 is 
physically different in many ways from the claimed invention's 'application program'. 
One difference is that there are a limited number of access protocols, i.e. http, ftp, gopher, 
telnet, etc. With the claimed invention, the number of application programs available to 
access a file is vastly greater: every application ever written that is capable of opening a 
file and that has a GUI. This constitutes both a physical difference under § 102 and an 
advantage over Simonoff under § 103. 

The claimed invention's access protocol is essentially thin-client enabled 'terminal 
emulation' access to server-based applications that have GUIs. Currently there is no URL 
access protocol which uses GUI-terminal emulation. This is an unobvious difference 
under § 103 due to the numerous unexpected and useful results as detailed in the 
specifications. 

Selecting Application Program After Hyperlink Activation Is Unobvious Under § 
103. Selecting a server-based application program after URL activation is unobvious 
under § 103 because it results in new and unexpected capabilities over Simonoff and the 
inherent features of an HTML file. One such advantage is that this feature allows the 
application program to be varied based on information gathered after a URL is activated, 
such as the identity of the accessing party, which intrinsically cannot be known at the 
time of URL creation (and access protocol assigning). 
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The Combination is Unobvious Under § 103. The suggested combination is unobvious 
under § 103 because it results in an unobvious and valuable advantage- the selection of 
the application program can be modified based on information received after a hyperlink 
is activated, i.e., whether a user has a legal right to use a particular program. This is 
impossible with a normal URL accessing a HTML document. As is well-known in the 
art, the association or linking of a file network location and an access protocol happens at 
the time the URL is created, NOT AFTER. It is clear that association is not the same as 
implementation, that is, carrying out a prespecified act. 



The Rejection of Claim 135 Is Overcome 

Claim 135 Is Dependent on Claim 132, and so meets Requirements of § 102 and § 103. 

Claim 135 is dependent upon, and incorporates all of the limitations of, claim 132. Therefore, 
since claim 132 meets novelty and unobviousness requirements of § 102 and § 103 as detailed 
above, so also does claim 135. 

Claim 135 was rejected because the Office Action stated that Lazaridis-Shachar discloses 
multiple application programs are available to be associated with the computer file, and the 
associated application program is selected based on selection criteria chosen from the group 
comprising: (a) legal rights of the user to use the application programs as a design choice; (b) 
capabilities of the application programs; and (c) properties that are associated with the hyperlink 
[Lazaridis, configured to create triggering events, col 2 line 67 et seq.] 

Lazaridis-Shachar Cannot Function As Claimed. As detailed above under the discussion of 
claim 132, the Lazaridis triggering events (push technology) is fundamentally different from 
hyperlink access to a file (pull technology), and cannot function in the way claimed by the 
present invention. 
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An example of the functioning of claim 135(a) would be acquiring identifying data about a 
recipient after hyperlink activation and using that data to determine which application programs 
the recipient has a right to use, for instance by looking up the recipient in a database showing 
which users have purchased the rights to use Microsoft Project. This cannot be done with 
Lazaridis-Shachar because that combination is push technology, where no data is collected about 
the recipient prior to pushing (forwarding) the data file to the recipient. This is because 
Lazaridis-Shachar assumes the recipient to be a single, unchanging individual, in contrast to the 
claimed invention. 

The Rejection of Claim 141 Is Overcome 

Claim 141 Is A Machine Claim Containing Limitations Similar to Claim 132, and so meets 
Requirements of § 102 and § 103. For the reasons detailed above for claim 132, claim 141 
meets the novelty and unobviousness requirements of the applicable statutes. Specific reasons for 
the rejection of claim 141 raised by the O.A. are discussed next. 

Claim 141 was rejected for reasons similar to Claim 132 except for the addition of subparagraph 
(g), to wit: an initiator component that, upon detection of the hyperlink activation, opens the 
computer file in said application program and transmits the graphical user interface of said 
application program to the thin client operating on the remote computer, whereby control and 
protection of the computer file is retained, while giving appropriate access to recipients via said 
server-based applications delivered via thin client [Lazaridis, intranet based program, col 4 lines 
19-38]. 

Misunderstood Citation. The full citation actually reads "The user data items ...can be 
stored... at the user's PC. Using this ...configuration, one redirector program can serve a 
plurality of users. This ...configuration could also include an internet-or intranet-based redirector 
program that could be accessible through a secure webpage or other user interface." From this it 
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can clearly be seen that the intranet based program referred to by Lazaridis is not an application 
program. Rather it is the data forwarding program or algorithm. In this context, it refers to a 
server pulling data items from a user's pc and forwarding them to the user's mobile device. The 
data item is NOT loaded into an application program for presentment to the user. 

Applicant respectfully refers the Examiner to the arguments for claim 132, above. Applicant 
believes that these arguments adequately answer the reasons for the rejection of claim 141 that 
are similar to claim 132 and detail the novelty, utility and unobviousness requirements of statute. 

The Rejections of Claim 142 and 187 Are Overcome 

Claim 187 is simply a method claim of the machine of claim 142, and meets requirements of § 
102 and § 103 as detailed below for claim 141 . 

Claim 142 Is Dependent on Claim 141, and so meets Requirements of § 102 and § 103. The 

machine of Claim 142 is dependent upon, and incorporates all of the limitations of, claim 141. 
Therefore, since claim 141 meets the novelty and unobviousness requirements, so also does 
claim 142. Specific reasons for the rejection of claim 142 raised by the O.A. are discussed next. 

Claims 142 was rejected because the Office Action stated that Lazaridis-Shachar discloses the at 
least one processing unit is selected from the group consisting of (a) a single server; (b) a 
personal computer; and (c) multiple separate computers operating as a single, logical server 
{Lazaridis, LAN, col 10 lines 21-38]. 

The full citation actually reads "The desktop system is connected to LAN 14 and can send and 
receive data, messages signals, event triggers, etc. to and from other systems connected to the 
LAN and to external networks." There is no suggestion that the other systems are a functional, 
integrated part of the desktop system, i.e., multiple computers operating as a single logical 
server, as claimed. 
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Claim 142 is simply a reification of the term 'at least one processing unit' from claim 141. In 
view of the arguments presented above that claim 141 is valid, applicant respectfully submits 
that claim 142 is now in a position of allowance. 



The Rejection of Claim 151 Is Overcome 

Claim 151 was rejected for reasons similar to claim 132. Applicant respectfully refers the 
Examiner to the arguments for claim 132, above. Applicant believes that these arguments 
adequately answer the reasons for the rejection of claim 151 that are similar to claim 132. 

Claim 151 was also rejected because the Office Action stated that Lazaridis-Shachar discloses: 

(i) providing computer software executable code on said computer server system for 
transmitting the human interface of said file-compatible server-based computer application to the 
at least one remote recipient user computer and to receive inputs to said interface from the at 
least one hyperlink recipient user [Shachar, hyperlink, col 16 lines 48-67, Fig. 11]. 

Misunderstood Reference. The actual citation is: "the user can ...interact with... a hyperlink 
that would invoke screen 4. Assuming screen 4 is invoked, ...the appropriate hypertext 
document is retrieved." From this it can clearly be seen that there is no suggestion in Lazaridis- 
Shachar to use a thin client to transmit the GUI of a remote application to a recipient user. 
Rather, the reference refers to simply presenting a hypertext document to the user via a web 
browser, as is well known in the art. 

The Rejection of Claim 152 Is Overcome 

The method of Claim 152 Is Dependent on Claim 151, and so meets Requirements of § 102 

and § 103. Claim 152 simply adds the additional step of the creation of the hyperlink of claim 
151, and incorporates all of the limitations of claim 151. Therefore, since claim 151 meets the 
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novelty and unobviousness requirements of the applicable USC, as demonstrated above, so also 
does claim 152. Specific reasons for the rejection of claim 152 raised by the O.A. are discussed 
next. 

Claim 152 was rejected because the Office Action stated that Lazaridis-Shachar disclose 
providing computer software executable code for creating said application file hyperlink and 
associating the hyperlink with said at least one computer file [Shachar, hyperlink, col 16 lines 
48-67, Fig. 11]. 

While it is true that Shachar does refer to a hyperlink which invokes a hypertext document such 
as an address book entry, this is physically different from the claimed invention because there is 
no suggestion in Lazaridis-Shachar to use a thin client to transmit the GUI of a remote 
application to a recipient user. This difference constitutes a patentable claim because it causes 
new, unobvious, and useful results, as detailed in the specifications and elsewhere in this reply. 

The Rejection of Claim 153 Is Overcome 

The method of claim 153 is dependent on claim 151, and so meets requirements of § 102 
and § 103. Claim 153 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 153. Specific reasons for the rejection of claim 153 raised by the O.A. 
are discussed next. 

The Office Action stated that Lazaridis-Shachar discloses providing computer software 
executable code for transmitting said application file hyperlink to said at least one hyperlink 
recipient user [Shachar, col 13 lines 32-40], 

According to the O.A. citation, a web page is downloaded in response to activating a URL. 
However, the cited text does not address how the URL is transmitted to the user. 
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The arguments mentioned above under the remarks for claim 151 demonstrate clearly that claim 
151 is novel under §102 and unobvious under §103. The additional step of URL transmission 
(claim 153) is also unobvious because it results in new, unobvious, and useful results, to wit 
giving an unlimited number of anonymous third party users seamless and effortless access to any 
combined file/compatible-application whatsoever. A hyperlink could be included on a web page. 
Clicking on a link on a financial adviser's web page might bring up a spreadsheet file within the 
spreadsheet application, with a template for a prospective customer to enter personal 
information, and perhaps run macros to see how much money the financial adviser could save 
him if he employs the adviser. This is much more robust and reliable than simply converting a 
spreadsheet to a web page, since the full functionality of the spreadsheet remains available to the 
viewer. 

The Rejections of Claims 154-156 Are Overcome 

The method of claims 154-156 are dependent on claim 151, and so meet the requirements of 
§ 102 and § 103. Claims 154-156 incorporate all of the limitations of claim 151. Therefore, since 
claim 151 meets the novelty and unobviousness requirements of the applicable USC, as 
demonstrated above, so also does claim 154-156. Specific reasons for the rejection of claim 154- 
156 raised by the O.A. are discussed next. 

The Office Action stated that Lazaridis-Shachar discloses said communications network 
comprises an Internet; a local area network; a uniform resource locator [Lazaridis, Internet, 
LAN, email]. 

Claims 154-156 are simply reifications of the terms 'communications network' and 'hyperlink 1 
from claim 151. In view of the arguments that claim 151 is valid, applicant respectfully submits 
that claims 154-156 are now in a position of allowance. 
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The Rejection of Claim 157 Is Overcome 

The method of claim 157 is dependent on claim 151, and so meets requirements of § 102 
and § 103. Claim 157 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 157. Specific reasons for the rejection of claim 157 raised by the O.A. 
are discussed next. 

The Office Action stated that Lazaridis-Shachar discloses (a) disassociating said application file 
hyperlink from said at least one computer file; and (b) associating said application file hyperlink 
with at least one different computer file [Shachar, hyperlink, col 16 lines 48-67, Fig. 11]. 

Lazaridis-Shachar never mention a hyperlink associated with a file and a remote application, as 
detailed above in the arguments for claim 132. Therefore, it would not be logical for Lazaridis- 
Shachar to teach dissociating said hyperlink from a specific computer file and reassociating it 
with a different file. 

Physical Difference, New and Unexpected Results. The reference does not refer to 
disassociating and reassociating a hyperlink. It simply refers to a hyperlink accessing a hypertext 
document. This step added to the method of claim 151 is patentable because it results in new, 
unobvious, and useful results, to wit: Changing the file associated with an AppLink after the 
AppLink has been created would be useful when getting the AppLink into the hands of its 
intended recipients is expensive or time-consuming, or when the sender does not know who has 
received an AppLink. An example of this would be the case where a number of people 
(unknown to the AppLink creator), after viewing an AppLink embedded in a web page, have 
added an AppLink URL to their web browser bookmark list. It would be impossible to send a 
new URL to these people. Similarly, a web-based newsletter publisher could send a single 
AppLink to his subscribers, instead of sending the subscribers a different AppLink every month. 
Each month he would associate that AppLink with a different document, that is, the latest 
newsletter. 
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The Rejection of Claim 158 Is Overcome 

The method of claim 158 is dependent on claim 151, and so meets requirements of § 102 
and § 103. Claim 158 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 158. Specific reasons for the rejection of claim 158 raised by the O.A. 
are discussed next. 

The Office Action stated that Lazaridis-Shachar discloses modifying the application interface 
capability function settings of said file-compatible server-based computer application [Shachar, 
GUI services, col 15 lines 5-32]. 

Misunderstood Citation. The cited GUI services refer to a component of a web browser 
which updates the PC display of the user. It does not refer to the GUI of a remote, thin- 
client delivered application. The words "application program" are included in the citation 
but refer to a browser program running locally [Shachar, the browser application program 
(event 4) now becomes active. . .col 15 line 14]. It does not refer to an application remote 
from the user, as claimed. 

Physical Difference. In any case, Lazaridis-Shachar does not disclose associating a 
hyperlink with a specific file and server-based application, as detailed above in the 
arguments for claims 151 and 132. Therefore, Lazaridis-Shachar does not disclose 
modifying the interface of said server-based application. It is the combination of said 
hyperlink with the modification of the server-based application's interface which is novel. 

Valuable, new, improved, and unexpected results. The combination of said hyperlink 
with the modification of the server-based application's interface results in new and 
unexpected results, as detailed in the specifications. 
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For example, varying the server-based application's interface can improve the sender's 
objectives and the receiver's user experience. If the sender has the objective of allowing a 
viewer to only view and not modify a file, then menu items associated with modifying the 
file can beneficially be removed. By simplifying the application interface (removing 
menu items, buttons, etc.), a user can have an easier time of it. For example, if AutoCAD 
is the server-based application, it is well-known that AutoCAD has an extremely complex 
interface to create and alter CAD files. However, a viewer who is not going to modify the 
file would only have need of viewing and rotating tools. 

Because legacy applications have not been designed as communications tools, modifying 
the GUIs was not contemplated by the designers. This is the unexpected part. The 
claimed invention makes every legacy application with a GUI into a means of 
communication. 



The Rejection of Claim 159 Is Overcome 

The Office Action stated that Lazaridis-Shachar discloses the recipient user computer is of a type 
selected from the group consisting of: (a) a personal computer; (b) a personal digital assistant; (c) 
a web or internet appliance device; and (d) a television set-top box as inherent feature of web 
applications. 

Claim 159 incorporates all of the limitations of claim 151, and is simply an explanation and 
reification of claim 151's term 'recipient user computer', as detailed in the specifications. 
Therefore, since claim 151 meets the novelty and unobviousness requirements of the applicable 
USC, as demonstrated above for claims 151 and 132, so also does claim 159. 



The Rejection of Claim 160 Is Overcome 
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The method of claim 160 is dependent on claim 152, and so meets requirements of § 102 
and § 103. Claim 160 incorporates all of the limitations of claim 152. Therefore, since claim 152 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 160. Specific reasons for the rejection of claim 160 raised by the O.A. 
are discussed next. 

The Office Action stated that Lazaridis-Shachar discloses the graphical user interface of said 
computer software executable code comprises a web page form [Shachar, HTML, Fig 2]. 

As discussed under claim 152, Lazaridis-Shachar does not disclose associating a hyperlink with a 
specific file and server-based application, as detailed above in the arguments for claims 151, 132, 
and 152. Therefore, Lazaridis-Shachar does not disclose a means to create such a hyperlink. It is 
the combination of said hyperlink with a step to create said hyperlink which is novel. 

The citation 'HTML 1 refers to a web form. Claim 160 is simply an explanation and reification of 
claim 152's term 'graphical user interface of said hyperlink generation means 1 , as detailed in the 
specifications. 

The Rejection of Claim 161 Is Overcome 

The method of claim 161 is dependent on claim 151, and so meets requirements of § 102 
and § 103. Claim 161 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 161. Specific reasons for the rejection of claim 161 raised by the O.A. 
are discussed next. 

The O.A. stated that Lazaridis-Shachar discloses providing computer software executable code 
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whereby said recipient user's access to and manipulation of said at least one computer file is 
variable and can be set for specific sessions according to specified parameters [Shachar, permit 
access, col 8 lines 5-16]. 

Physical Difference. The foil Shachar citation is: "The data communications network 122 
permits access to one or more service providers 124". There is no discussion of variable access 
to and manipulation of computer files via remote thin-client delivered applications, as claimed. 
Rather, the Shachar prior art refers to accessing various HTML-based services and the related 
web pages. Nowhere does Lazaridis- Shachar discuss file access restrictions. Because Lazaridis- 
Shachar does not contemplate using server-based applications as a means of hyperlink-enabled 
broad communication, they do not disclose ways to restrict or modify such communication. 

Valuable, new, improved, and unexpected results. The combination of said hyperlink with file 
access and restriction means results in new and unexpected results, as detailed in the 
specifications. 

For example, applicable application functionality restrictions may include the following: 
read/write, read-only, no printing, no editing, no copying, or various other restriction on 
application functions as applied to the particular file. The restrictions may also be event or time- 
based, e.g., there may be a restriction that a user may access the file a certain number of times, 
view until a particular date. The access may also be based on the access location of a remote 
user, e.g. a user may only access the file from a certain IP address or modem phone number, or 
conversely, may NOT access the file from certain IP addresses or phone numbers. This may 
prevent unauthorized access when authentication information is compromised, or during a duress 
situation, or to prevent applications from being used in countries where export laws prohibit use. 

The Rejection of Claim 162 Is Overcome 

The method of claim 162 is dependent on claim 151, and so meets requirements of § 102 
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and § 103. Claim 162 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 162. Specific reasons for the rejection of claim 162 raised by the O.A. 
are discussed next. 

The Office Action stated that Lazaridis-Shachar discloses the file restriction means comprises a 
partially disabled file-compatible server-based application [Shachar, permit access, col 8 lines 5- 
16]. 

Physical Difference. The full Shachar citation is: "The data communications network 122 
permits access to one or more service providers 124". The reference does not refer to a partially 
disabled server-based application, as claimed. There is no discussion of variable access to and 
manipulation of computer files via remote thin-client delivered applications, as claimed. Rather, 
the Shachar prior art refers to accessing various HTML-based services and the related web 
pages. Nowhere does Lazaridis-Shachar discuss file access restrictions. Because Lazaridis- 
Shachar does not contemplate using server-based applications as a means of hyperlink-enabled 
broad communication, they do not disclose any way to restrict or modify such communication, 
including the claimed partially disabled file-compatible server-based application. 

Valuable, new, improved, and unexpected results. The combination of said hyperlink where 
the file access and manipulation restriction means are comprised of partially disabled server- 
based applications results in new and unexpected results, as detailed in the specifications. For 
example, when accessing files, users click on a hyperlink to open the document in the proper 
application. Each user may be granted a security clearance level, for example, based upon rank, 
position, department, or other criteria. In addition to the user security level, each file preferably 
will also have a security level The combination of the file security level and user security 
clearance level determine which files are available and the user's level of access. For example 
the user may or may not be able to edit, save, save as, print, copy, or the like, depending on the 
granted access level. 
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As another example, application licensing may impact application functionality. Various 
application versions may have different functionality for legal reasons. That is, licensing terms 
may require differing levels of functionality for different payments to the vendor or different 
circumstances. A "demonstration" license might require disabled functionality. In certain 
situations, AppLink recipients may actually pay for and/or subscribe to certain functions or 
subsets of functions, eliminating those that they would not use from the interface and simplifying 
their experience of the application. 



The Rejection of Claim 163 Is Overcome 

The Office Action stated that Lazaridis-Shachar discloses said file restriction means comprises a 
partially disabled thin-client application means [Lazaridis, palm top computer, seamless, 
transparent redirection of user-selected data items, col 6 lines 31-48]. 

The method of claim 163 is dependent on claim 161 which is dependent on claim 151, and 
so meets requirements of § 102 and § 103. Claim 163 incorporates all of the limitations of 
claim 151. Therefore, since claim 151 meets the novelty and unobviousness requirements of the 
applicable USC, as demonstrated above, so also does claim 163. Specific reasons for the 
rejection of claim 163 raised by the O.A. are discussed next. 

Previous Office Action Acknowledged That Lazaridis Does Not Detail Operating a 
Thin Client on the Local Computer As acknowledged by the O.A. mailed 08/13/2004, 
page 3, lines 1-2. Since Lazaridis does not teach using a thin client (the words thin client 
are not found in the cited patent), he could not teach using a disabled version. 

Valuable, new, improved, and unexpected results. The same advantageous, 
unexpected, and unobvious results as detailed above for claim 162 are also applicable 
here, because a disabled thin client is an alternative way of accomplishing the same result 
as a modified application interface. 
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The Rejection of Claim 171 & 177 Is Overcome 

The Office Action stated that Lazaridis-Shachar discloses (a) providing executable code on said 
computer server system for producing a computer visual interface desktop work area, (b) 
providing access to or links to zero or more additional applications on the visual interface 
desktop, (d) providing access to or links to said at least one computer file or document on the 
visual interface desktop; and wherein said thin client means on said at least one remote recipient 
computer are adapted to receive and display said computer visual interface desktop work area 
[Shachar, permit access, col 8 lines 5-16]. 

The method of claims 171 & 177 are dependent on claim 151, and so meets requirements of 
§ 102 and § 103. Claim 171 & 177 incorporate all of the limitations of claim 151. Therefore, 
since claim 151 meets the novelty and unobviousness requirements of the applicable USC, as 
demonstrated above, so also does claim 171 & 177. Specific reasons for the rejection of claim 
171 & 177 raised by the O.A. are discussed next. 

Physical Difference. The full Shachar citation is: "The data communications network 122 
permits access to one or more service providers 124". There is no discussion of access to and 
manipulation of computer files via remote thin-client delivered applications through a computer 
visual interface desktop work area, as claimed. Rather, the Shachar prior art refers to accessing 
various HTML-based services and the related web pages. Lazaridis-Shachar does not teach using 
thin clients, and so do not teach using a thin-client GUI desktop to provide file access and 
manipulation. 

Valuable, new, improved, and unexpected results- Claim 171. This embodiment of sending a 
file or files within a GUI desktop makes possible links that would otherwise be impracticable. 
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For example, with some programs, such as Adobe Photoshop™ or the Linux GIMP image 
editing program, the program works with multiple windows which can be minimized, moved, 
and resized, and which serve various specialized functions, for example as tool and color 
palettes. Multiple windows cannot readily be web-enabled by existing web-enabling 
applications. Also, those web-enabling applications have some limitations on window sizes. For 
example, the Tarantella™ web-enabling application does not have infinitely resizable application 
windows for Microsoft Windows applications; it is limited to fixed, preset application window 
sizes (such as 800x600) as set by the Tarantella administrator. However, if Tarantella is used to 
web-enable a GUI desktop, then within the desktop any application windows are infinitely 
resizable. Also, all the advantages of a GUI desktop then become available to an AppLink 
recipient. For example, the Linux Gnome or KDE desktop has "virtual desktops," which extend 
the working area of the user's screen up to 32-fold. An application that is web-enabled directly, 
rather than within a GUI desktop, will typically have a working area limited to the application 
window size. 

Valuable, new, improved, and unexpected results- Claim 177. A single AppLink may be 
hyperlink to a number of different files, such as a group of files relevant to a project. Suitable 
ways of implementing a multiple file AppLink include but are not limited to the following: A 
multi-file AppLink could simply bring the recipient to a web page that then has multiple links, 
one for each file. The recipient would then click on each individual link to view each file. 
Alternatively, a multi-file AppLink would open each file in its own application window all at 
once when it is activated. 

The Rejection of Claim 180 Is Overcome 

The Office Action stated that Lazaridis-Shachar discloses providing means for at least one 
additional user using at least one additional remote user computing device to view and optionally 
interact with the interface of said file-compatible server-based computer application, whereby the 
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additional user and the first hyperlink recipient user may engage in simultaneous collaboration 
over said file [Lazaridis, intranet based program, col 4 lines 19-38]. 

The method of claim 180 is dependent on claim 151, and so meets requirements of § 102 
and § 103. Claim 180 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 180. Specific reasons for the rejection of claim 180 raised by the O.A. 
are discussed next. 

Physical difference. The purpose of Lazaridis' s invention is to forward a data file, 
principally email and attachments, to various external machines (Lazaridis, the present 
invention includes the ability to redirect certain message attachments to... an external 
machine which could be a FAX machine, a printer, a system for displaying images or a 
voice mail system, col 6 lines 9-13). It does not teach using server-based computer 
applications to open the file, therefore it cannot teach sharing such applications among 
multiple users in simultaneous collaboration. 

Valuable, new, improved, and unexpected results. Because the application file 
hyperlink allows links to server-based applications and files to be easily pasted into 
publicly-available web pages, this capability would allow the hyperlink originator the 
capability of instant collaboration with one or more anonymous persons who happen to 
have activated the hyperlink. Such a capability was not a part of the art at the time of 
invention. It is the ability to seamlessly combine asynchronous communication (where 
both parties are not required to be online at the same time, like email) with synchronous 
communication ( like instant messaging, or application sharing, where both persons must 
be online at the same time) which is new, improved and unexpected. 
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The Rejection of Claim 181 Is Overcome 

The method of claim 181 is dependent on claim 151, and so meets requirements of § 102 
and § 103. Claim 151 is physically novel over Lazaridis-Shachar , as detailed in the remarks for 
that claim. Therefore, using the invention of claim 151 as a business method in claim 1 8 1 is also 
novel. Specific reasons for the rejection of claim 181 raised by the O.A. are discussed next. 

The Office Action stated that Lazaridis-Shachar discloses providing subscription means 
associated with said service whereby a remote hyperlink recipient user who is not a subscriber of 
said entity is solicited to subscribe to said service [Shachar, permit access, col 8 lines 5-16]. 

Physical Difference. The full Shachar citation is: "The data communications network 122 
permits access to one or more service providers 124". There is no discussion of access to and 
manipulation of computer files via remote thin-client delivered applications, as claimed. Rather, 
the Shachar prior art refers to accessing various HTML-based services and the related web 
pages. Lazaridis-Shachar does not teach using thin clients at all, and so does not teach using thin- 
client access to files and applications as a business viral marketing method. 

Valuable, new, improved, and unexpected results. According to the present invention, 
an AppLink may be implemented as a viral marketing mechanism for service providers 
as follows: A link or other mechanism may be included in some or all sent AppLinks, 
depending for example on the subscription level of the sender or creator, whereby an 
AppLink recipient is advised or solicited regarding signing up with the service provider 
that is providing the AppLink capability to enable the recipient to send their own 
AppLinks. In this manner, incentive is provided to the recipient to sign up or register. 
According to this embodiment of the present invention, the novel capability of AppLink 
to deliver server-based applications and files to a broad range of anonymous or random 
recipients allows AppLink to be used as a viral marketing mechanism. Viral marketing 
typically may be thought to require two components: (1) a user motivated to use a 
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service to communicate with others that are not currently members of the service, and (2) 
provision for nonmembers that are communicated with to sign up for the service. Since 
an AppLink is essentially a new and useful way to communicate with any number of 
recipients, it intrinsically provides the first component. The second condition can be 
satisfied by including a registration form or a link included in a recipient's introductory 
web page, for sent AppLinks which, if activated by the AppLink recipient, brings an 
AppLink recipient to an informational web page which would include that ability to 
register with the service, perhaps through a limited time offer. 

Another example: Another embodiment where the use of AppLinks can act as a viral 
marketing mechanism for Software Vendors or publishers is by way of an AppLink 
Recipient Demo Application License. According to this embodiment, a free "demo" 
license for AppLink recipients allows software vendors to present their application to 
potential customers via the viral marketing mechanism of AppLink. 

The Rejection of Claim 182 Is Overcome 

The Office Action stated that Lazaridis-Shachar discloses a log of accesses to said computer file 
is kept on said computer server system [Shachar, permit access, col 8 lines 5-16]. 

The method of claim 182 is dependent on claim 151, and so meets requirements of § 102 
and § 103. Claim 182 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 182. 

Specific reasons for the rejection of claim 182 raised by the O.A. are discussed next. 
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Physical Difference. The full Shachar citation is: "The data communications network 122 
permits access to one or more service providers 124". There is no discussion of access to and 
manipulation of computer files via remote thin-client delivered applications, as claimed. Rather, 
the Shachar prior art refers to accessing various HTML-based services and the related web 
pages. Lazaridis-Shachar does not teach using thin clients at all, and so does not teach keeping a 
log of such accesses. 

Valuable, new, improved, and unexpected results. According to the present invention, 
settable AppLink properties pertaining to access tracking may include, but are not limited 
to, recordation and/or notification of: each individual access or given number of 
accesses; the ID data of each accessor; the time of access of one recipient or the 
consolidated or average access time of a group of recipients; the AppLink session time; 
the file access and/or manipulation details; or the interaction playback of a recipient 
session. 

The extreme detail of recorded access far exceeds a simple email receipt. For example, if 
a data file is sent as an email attachment, no information about its opening or use is 
available. In contrast, in the claimed invention, because the file remains on the server and 
the application runs there also, every detail of its access and manipulation can be 
recorded (up to and including actual session playback) for tracking or any other purpose. 
These are valuable, new, improved, and unexpected results flowing from the act of 
recording access details. 

The Rejection of Claim 188 Is Overcome 

The method of claim 188 is dependent on claim 151, and so meets requirements of § 102 
and § 103. Claim 188 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 188. Specific reasons for the rejection of claim 188 raised by the O.A. 
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are discussed next. 

The Office Action stated that Lazaridis-Shachar discloses the computer software executable code 
which detects the execution of the hyperlink by said hyperlink recipient user over said 
communications network operates on a computing device physically separate from separate from 
the remainder of said server system but connected through said communications network. 
[Shachar, col 13 lines 32-40]. 

Physical Difference. It was well known in the art that a HTML service module can detect the 
user's interaction with a hyperlink which is associated with a computer file, as detailed in the 
Shachar citation. However, Lazaridis-Shachar do not disclose using a thin-client application to 
open a file associated with a hyperlink. 

Valuable, new, improved, and unexpected results. Because most PCs do not have a web 
server capability installed, separating out this capability into the server system, and having the 
server system utilize the PC as a file storage and application server would allow AppLink 
capability to easily be extended to ordinary PCs with minimal modification. That is, said server 
system would incorporate PCs connected to the network as the part of the server system that 
functions as file and/or application servers. This results in whatever applications a user has 
installed on his PC (however esoteric) being available for AppLink usage. Therefore the rest of 
the server need not have numerous rarely used applications installed. 

From the specifications: 

The present invention may be implemented via an AppLink creator's own Internet- 
connected computer, with the creator's machine performing the functions of an AppLink 
Server and Application Server. In order for this implementation to be transparent to the 
recipient, this computer will preferably remain connected to the network at all times. 
Accordingly, ISPs and website hosting services, as well as entities or individuals 
maintaining their own internet servers, may in many cases implement this capability 
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almost immediately. In the situation in which an AppLink incorporates a file not resident 
on the AppLink Server, e.g., the file is stored on a different Network-connected computer 
or data storage device than the AppLink Server, the AppLink Server preferably will 
record the location of the file at the time the AppLink is created, and will use a system to 
open it from that location, or it will upload a copy of the file to the AppLink Server. An 
Application Server must be able to access the file being AppLinked in order to open and 
run it within an appropriate server-based application. 



The Rejection of Claim 189 Is Overcome 

The O.A. states that Lazaridis-Shachar discloses one of said multiple, separate computers 
operating as a single, logical server comprise a separate computer operating as an application 
server [Lazaridis, email sub system 44, Fig 3]. 

Misunderstood Citation. Fig 3 clearly shows an e-mail sub-system as a part of a single desktop 
computer (not multiple, separate computers) as seen by the box enclosing multiple elements 
(including the email subsystem) labeled "desktop computer'. [Lazaridis, The cited figure shows 
the interaction of the redirector software 12 with additional components of the host system 10 of 
Fig. 1 (the desktop PC), col 10 lines 10-12]. Thus the claimed invention is not disclosed by 
Lazaridis-Shachar. 

Physical Difference. Claims 189 and 189a incorporate the application file hyperlink of 
claim 151 and so are novel as detailed in the comments for claims 151 and 132. Physical 
differences are similar to those mentioned for claim 188. 

Valuable, new, improved, and unexpected results. Because most PCs do not have a 
web server capability installed, using a PC as a file storage and application server would 
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allow AppLink capability to easily be extended to ordinary PCs with minimal 
modification, and with the creator's PC performing the functions of an application server 
and/or file server. In order for this implementation to be transparent to the recipient, this 
computer will preferably remain connected to the network at all times. Accordingly, 
ISPs and website hosting services, as well as entities or individuals maintaining their own 
internet servers, may in many cases implement this capability almost immediately. 

Claim 190 Is Withdrawn 



The Rejection of Claim 191 Is Overcome 

The method of claim 191 is dependent on claim 151, and so meets requirements of § 102 
and § 103. Claim 191 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 191 . 

The Office Action stated that Lazaridis-Shachar discloses downloading the thin client from the 
server system to said at least one remote recipient user computing device [Lazaridis, palm top 
computer, col 6 lines 3 1 -48] . 

Previous Office Action Acknowledged That Lazaridis Does Not Detail Operating a 
Thin Client on the Local Computer As acknowledged by the O.A. mailed 08/13/2004, 
page 3, lines 1-2. Since Lazaridis does not teach using a thin client (the words thin client 
are not found in the cited patent), he could not teach downloading it to a recipient user. 

Valuable, new, improved, and unexpected results. Downloading the thin client to the 
recipient's PC allows the claimed invention to give file and application access via 
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hyperlink to virtually any internet-connected computing device. Because the present 
invention's intent is to allow anonymous, third-party access to remote applications and 
files, it incorporates steps to assure compatibility of a recipient's PC to receive and 
display the remote application and file, i.e., to ensure that a compatible thin client is 
present on the recipient's PC, by downloading one if one is not already present. 

This results in the many advantages of said application file hyperlink, as outlined in the 
comments for claim 151 and 132, being made available to most if not all personal 
computing devices, and thus extending its utility as a communications method. 



The Rejection of Claim 192 Is Overcome 

The method of claim 192 is dependent on claim 191, and so meets requirements of § 102 
and § 103. Claim 192 is essentially a narrowing of claim 191. Therefore, since claim 191 meets 
the novelty and unobviousness requirements of the applicable USC, as demonstrated above, so 
also does claim 192. 

Specific reasons for the rejection of claim 192 raised by the O.A. are discussed next. 

The Office Action stated that Lazaridis-Shachar discloses downloading the thin client occurs 
only after said at least one remote recipient user computing device is examined and found not to 
already have the thin client available [Lazaridis, palm top computer, col 6 lines 31-48]. 

Previous Office Action Acknowledged That Lazaridis Does Not Detail Operating a 
Thin Client on the Local Computer As acknowledged by the O.A. mailed 08/13/2004, 
page 3, lines 1-2. Since Lazaridis does not teach using a thin client (the words thin client 
are not found in the cited patent), he could not teach downloading it to a recipient user. 
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Valuable, new, improved, and unexpected results. Please see comments for claim 
191 , above, for details. 

The Rejection of Claim 193 Is Overcome 

The method of claim 193 is dependent on claim 151, and so meets requirements of § 102 
and § 103. Claim 193 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 193. 

The Office Action stated that Lazaridis-Shachar discloses opening the computer file occurs only 
after a determination is made that the hyperlink associated with the computer file is still active 
[Shachar, col 13 lines 32-40]. 

Physical Difference. The Shachar citation is for a fact well known in the art- that is, that a 
HTML service module can detect the user's interaction with a hyperlink which is associated with 
a computer file. However, Shachar does not suggest combining a hyperlink with remote thin 
client access to a file, as claimed. 

Valuable, new, improved, and unexpected results. This novel physical structure is unobvious 
because the invention as claimed allows protection of intellectual property (the computer file) by 
allowing a hyperlink creator to disable it at any time, thus cutting off access to the file. This 
valuable, unexpected result is in contrast to the alternative of an email attachment, which, when 
sent, is irretrievable, and in contrast to Lazaridis-Shachar , who do not address the issue of LP. 
protection at all. 

The Rejection of Claim 194 Is Overcome 

The method of claim 194 is dependent on claim 151, and so meets requirements of § 102 



Page 62 



Appn. Number 09/866,454 (Rice)VU 2142 Amendment C contd. 63 of 121 



and § 103. Claim 194 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 194. 

The Office Action stated that Lazaridis-Shachar discloses changes are made to the computer file 
after the hyperlink is created, and the hyperlink remains associated with the latest version of the 
computer file. [Shachar, col 13 lines 32-40], 

Physical Difference. The Shachar citation is for a fact well known in the art- that is, that a 
HTML service module can detect the user's interaction with a hyperlink which is associated with 
a computer file. However, Shachar does not suggest combining a hyperlink with remote thin 
client access to a file, as claimed. 

Physical difference. As detailed in the remarks for claim 132 and 151, Lazaridis-Shachar 
do not disclose a hyperlink associated with a specific file and thin-client delivered server- 
based application. Therefore, they do not detail what happens to such a file after creation 
of such a hyperlink. 

Valuable, new, improved, and unexpected results. Changing the file after hyperlink 
creation is unobvious because it results in the hyperlink being associated with the most 
current copy of a file, unlike an email file attachment, which cannot be updated. This 
capability also allows unexpected results like allowing a recipient to bookmark a 
particular application file hyperlink, said hyperlink for example always being connected 
to the latest issue of a subscription magazine. This is unobvious over a simple HTML file 
for the advantages detailed in the remarks for claims 132 and 151. 

The Rejection of Claim 195 Is Overcome 

The method of claim 195 is dependent on claim 151, and so meets requirements of § 102 
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and § 103- Claim 195 incorporates all of the limitations of claim 151. Therefore, since claim 151 
meets the novelty and unobviousness requirements of the applicable USC, as demonstrated 
above, so also does claim 195. 

Specific reasons for the rejection of claim 195 raised by the O.A. are discussed next. 

The Office Action stated that Lazaridis-Shachar discloses the application program is not 
operating on the remote computer until after the activation of the hyperlink is detected [Shachar, 
col 13 lines 32-40], 

Physical Difference. The Shachar citation is for a fact well known in the art- that is, that a 
HTML service module can detect the user's interaction with a hyperlink which is associated with 
a computer file. However, Shachar does not suggest combining a hyperlink with remote thin 
client access to a file, as claimed. 

Valuable, new, improved, and unexpected results. Starting the application program after the 
hyperlink is activated is unobvious because it allows the choice of the application program to be 
made using data not available until after the hyperlink is activated, such as data about the identity 
of the hyperlink activator (recipient), or data about what applications the recipient is legally 
allowed to use. This valuable result is not addressed or even contemplated by Lazaridis- 
Shachar. . 

The Claims Rejections Under 35 USC § 103 (a) 

Claims 172-176 were rejected as obvious over Lazaridis et al [Lazaridis, 6,219,694] in view of 
Beer et al [Beer, 5,864,676]. 

Office Action Objection 
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The Office Action stated that Lazaridis discloses (a) detecting said hyperlink activation and (c) 
opening the file copy in said file-compatible server-based application instead of the original 
computer file. However, Lazaridis does not explicitly detail assigning a guest account to said 
recipient user; and (b) creating a copy of said at least one computer file in the guest account. The 
O.A. goes on to state that it was well known in the art that the guest/visitor/temporary account 
was created for the short time user on network such as internet user. A skilled artisan would have 
motivation to improve the thin client access to internet and found Beer teaching. Beer taught 
URL login wherein the guest account is used for the URL login [Beer, guest account, col 1 lines 
29-38; Java applet, col 1 lines 59-col 2 line 7; col 3 lines 48-55]. Therefore it would have been 
obvious to an ordinary skill in the art to incorporate the guest account as taught by Beer into 
Lazaridis apparatus in order to utilize the thin client. Doing so would provide security to the thin 
client to access and execute Internet application locally. 

The Objections to Claims 173-176 Are Overcome 

Previous Office Action Acknowledged That Lazaridis Does Not Detail Operating a Thin 
Client on the Local Computer The O.A. mailed 08/13/2004, page 3, lines 1-3 state: "Lazaridis 
does not explicitly detail (e) operating a thin client on the local computer, the thin client allowing 
the user to provide input to and receive output from the application program running on the 
remote computer." 

Since Lazaridis does not teach using a thin client (the words thin client are not found in the cited 
patent), it would not be possible for a skilled artisan to combine .a Lazaridis thin client with a 
Beer guest account. 

The O.A. stated that "However Lazaridis does not explicitly detail assigning a guest account to 
said recipient user; and (b) creating a copy of said at least one computer file in the guest account. 
It was well known in the art that the guest/visitor/temporary account was created for the short 
time user on network such as Internet user." 
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Account types physically different from known art. The O. A assertion that guest/temp 
accounts were well known in the art is not correct. There is no suggestion that an account 
of the type needed for running an application with a GUI, such as Microsoft Word, be 
used as a guest account or be created prior to use for temporary usage. This is because 
computer system accounts of this type were known in the art to be used only with named 
user usage. There was no suggestion that multiple unnamed users would access a given 
desktop-type application user account, because to give multiple users access to each 
user's private files and applications would violate basic security practices. 

Without the novel advantages of the present invention, which convert legacy applications 
into a method of communication and collaboration, there is no reason to create a system 
to give access to such application user accounts, or to manage them before and after 
access. 

The O.A. goes on to state that "A skilled artisan would have motivation to improve the thin client 
access to Internet and found Beer teaching. Beer taught URL login wherein the guest account is 
used for the URL login {Beer, guest account, col 1 lines 29-38; java applet, col 1 lines 59-col 2 
line 7; col 3 lines 48-55]. Therefore it would have been obvious to an ordinary skill in the art at 
the time the invention was made to incorporate the guest account as taught by Beer into 
Lazaridis's apparatus in order to utilize the thin client. Doing so would provide the security to the 
thin client to access and execute Internet application locally." 

Beer Teaches Oppositely. The full Beer "guest account" citation makes clear that Beer 
actually teaches away from using a guest account: [Beer, a user may wish to log into a 
network via a public terminal. . .In such a situation there is no way to maintain a login 
account for every possible person who might use the public computer, and "guest" 
accounts have little or no real value, since they do not let a user access all of the 
resources to which that user has privleges." 
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In fact, the function of the Beer invention is to avoid using guest accounts and allow 
named users to access their own accounts and account resources remotely via the 
multiple login automation features of his invention. There is no suggestion anywhere of 
guest accounts being created for any purpose. 

The full Beer citation containing the words "java applet" make clear that the meaning is 
to allow the user to access files by the mechanism of downloading the file to the local 
machine and opening it in a java applet downloaded to the local machine also. [Beer, ...it 
is possible to bring small applications called "applets" from a server to a client and 
execute such applications locally, col 3 lines 50-52]. This is opposite to the claimed 
invention where the file stays on the server and the application runs there also. Again, no 
mention of guest accounts in the "java applet" citation. 

No suggestion to combine references. As detailed above, all the references mentioned 
by the O.A. teach oppositely to the meaning that the O.A. states they have. However, 
even if the meaning was as the O.A. states, there is no suggestion that they be combined 
as the O.A. suggests. 

Valuable, new, improved, and unexpected results. By creating a guest user application 
account on the server and copying the linked-to file into the guest account from the 
originator's account at the time of AppLink activation, security is obtained for the 
AppLink originator by not granting access to third parties to the originator's personal 
application account, and thus to other files or personal information not intended to be 
shared. 

From the specifications: Accessing an AppLink with a "dummy" user account rather than 
directly from the AppLink creator's account (with file access restrictions, of course), the 
damage which an unscrupulous, "hacker" AppLink recipient could do may be restricted. 
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For example, there would be no way for such a recipient to access or delete other files 
contained in an AppLink sender's service account. 



The Rejection of Claim 173 Is Overcome 

The Office Action stated that Lazaridis-Beer disclose the guest account is created after detecting 
said hyperlink activation. [Beer, guest account, col 1, lines 29-38]. 

Misunderstood Reference. As detailed in the remarks for claim 172, the citation teaches 
away from using a guest account. As a consequence, Beer does not address the question 
of when to create such an account. 

Valuable, new, improved, and unexpected results. Creating a guest user application 
account on a server requires substantial time and effort. Pre-creating a series of 
application accounts for fictional users speeds up functional response to AppLink 
activation by a recipient. In the art, there has been to date no need to pre-create such 
accounts because their use by other than named users has not been contemplated. 



The Rejection of Claim 174 Is Overcome 

The Office Action stated that Lazaridis-Beer disclose (a) deleting said guest account upon the 
closing of the computer file by the user, or (b) deleting or cleaning data items from said guest 
account and returning said guest account to available status upon the closing of the computer file 
by the user. [Beer, guest account, col 1, lines 29-38; java applet, col 1 lines 59-col 2 line 7; col 3 
lines 48-55]. 
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Misunderstood Reference. Please see the remarks for claim 172 which addresses the Beer 
citations. As mentioned therein, the citations teach away from using a guest account. As a 
consequence, Beer does not address the question of what to do with such accounts after they are 
used. 



The Rejection of Claim 175 Is Overcome 

The Office Action stated that Lazaridis-Beer disclose predefining a plurality of guest accounts, 
and further wherein one of the predefined guest accounts is assigned to the user after hyperlink 
activation [Beer, guest account, col 1, lines 29-38; java applet, col 1 lines 59-col 2 line 7; col 3 
lines 48-55]. 

Misunderstood Reference. Please see the remarks for claim 172 which addresses the Beer 
citations. As mentioned therein, the citations teach away from using a guest account. As a 
consequence, Beer does not address the question of what to do with such accounts in 
combination with the claimed invention's application file hyperlinks. 



The Rejection of Claim 176 Is Overcome 

The Office Action stated that Lazaridis-Beer disclose wherein said guest account is unassigned 
or returned to available status upon the closing of the computer file by the user [Beer, guest 
account, col 1, lines 29-38; java applet, col 1 lines 59-col 2 line 7; col 3 lines 48-55]. 

Misunderstood Reference. Please see the remarks for claim 172 which addresses the 
Beer citations. As mentioned therein, the citations teach away from using a guest account. 
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As a consequence, Beer does not address the question of what to do with such accounts in 
combination with the claimed invention's application file hyperlinks. 



The Rejections of Claims 136-140, 143-150, 165, 170, 183-186, 196-200 
Are Overcome 

The Office Action stated that the above claims were rejected under 35 USC § 103 as obvious 
over Lazaridis et al [Lazaridis, 6,219,694] in view of Shachar [5,923,736] and further in view of 
Shiigi [6,304,898 B 13]. 

The Rejection of Claim 136 

The Office Action stated that, as per claim 136, Lazaridis-Shachar discloses a method for 
handling incoming e-mails at an e-mail gateway [Lazaridis, gateway, email col 6 lines 1-67] see 
claim 132 rejection except: 

(f) operating a thin client on a local computer used by the recipient, the thin client 
allowing the recipient to provide input to and receive output from the application 
program running on the remote computer, whereby the file (e-mail) attachment 
cannot pose a virus danger to said local computer since it is manipulated remotely, 
and whereas the local computer has no need of a compatible program to open said 
attachment [Lazaridis, Intranet based program, col 4 lines 19-38; Shachar, permit 
access, col 8 lines 5-16]. However, Lazridis-Shachar does not detail explicitly the 
electronic file as email attachment. Shiigi discloses an electronic messaging system 
using JAVA applet (i.e.: thin client), Email server and gateway to send email with 
attachments [Shiigi, col 4 lines 43-63; col 5 line 34-col 6 line 67; col 7 lines 1-65]. It 
would have been obvious to incorporate the technique of using Email over the thin 
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client with Java applet into Lazaridis-Shachar apparatus. Doing so would allow the 
web user to compose, manipulate, send and view or print handdrawn messages. 

Please see discussion of claim 132 for reasons overcoming the O.A. objections for that claim. 

Misunderstood Lazaridis Citation. The full Lazaridis citation actually reads "The user data 
items .. .can be stored. . .at the user's PC. Using this . . .configuration, one redirector program can 
serve a plurality of users. This ...configuration could also include an internet-or intranet-based 
redirector program that could be accessible through a secure webpage or other user interface." 
From this it can clearly be seen that the intranet based program referred to by Lazaridis is not an 
application program. Rather it is the data forwarding program or algorithm. In this context, it 
refers to a server pulling data items from a user's pc and forwarding them to the user's mobile 
device. The data item is NOT loaded into an application program for presentment to the user. 

Physical Difference with Shachar. The full Shachar citation is: "The data communications 
network 122 permits access to one or more service providers 124". There is no discussion of 
variable access to and manipulation of computer files via remote thin-client delivered 
applications, as claimed. Rather, the Shachar prior art refers to accessing various HTML-based 
services and the related web pages. Nowhere does Lazaridis-Shachar discuss file access 
restrictions. Because Lazaridis-Shachar does not contemplate using server-based applications as 
a means of hyperlink-enabled broad communication, they do not disclose ways to use this 
invention in an email gateway. 

Shiigi Patent Summary. Shiigi discloses a method and system for creating and sending 
graphical email. One way it does this is to download a drawing JAVA applet which allows 
writing to be drawn freehand and saved as an image file, such as GIF. Another way is to upload 
the image file to a server, which analyzes the file and interprets the drawing/writing in terms of 
text. This text is then forwarded as a normal email. 

Misunderstood Reference: Shiigi JAVA Applet is not a thin client. The O.A. confuses java 
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applets with thin clients. A thin client can be composed of a java applet, but a java applet does 
not have to be a thin client. In the case of Shiigi's disclosure, the Shiigi JAVA applet refers to a 
Java drawing program that either accesses a web browser's email client, or incorporates such 
capability in itself [Shiigi, the handwriting messaging component is a Java applet downloadable 
to a web page for an email client of a standard web browser, col 2 lines 52-54]. There is no 
suggestion in Shiigi that the Java applet is a thin client. In fact, Shiigi does not mention the 
words "thin client" at all. 

Shiigi Email Client Operates Locally. Shiigi explicitly teaches that the email client is 
downloaded to the local PC, and does not operate remotely [Shiigi, in the preferred 
implementation, the server computer stores the graphical email handling software that is 
downloaded to the client computers, col 4 lines 29-32], if it does not utilize the email 
client of the web browser (see above comments for Shiigi JAVA applet). A web browser 
email client also operates locally, of course. 

Different Purpose. The Shiigi citation refers to a user sending an image of handwriting 
to another user in an Instant Messaging mode. This capability is not claimed by the 
present invention. 

No suggestion to combine references. As detailed above, all the references mentioned 
by the O. A. teach oppositely to the meaning that the O.A. states they have. However, 
even if the meaning was as the O.A. states, there is no suggestion that they be combined 
as the O.A. suggests. 

Lack of Implentation, Solves a Longfelt, Unsolved Need Costing $$ Billions. The 

claimed invention eliminates danger from viruses carries by email attachments, since it 
eliminates email attachments. Therefore there was economic motivation to devise this 
invention, yet this did not happen until the applicant developed the current invention, 
providing evidence that it is non-obvious. 
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Combination of Three References Unobvious As discussed above, the Applicant 
suggests that the interpretation taken by the O.A. of the three references (Lazaridis, 
Shachar, and Shiigi) is incorrect. Even if the interpretation were correct, to combine three 
references in the manner suggested 

The Rejection of Claim 137 Is Overcome 

The Office Action stated that claim 137 contains similar limitations set forth in claim 136, and so 
was rejected for the same rationale set forth in claim 136. 

Claim 136 has been clearly shown to be patentable under USC 103 as detailed above 
under the remarks for claim 136. Therefore, Applicant respectfully submits that claim 
137 is in an allowable form for similar reasons. 

The Rejection of Claim 138 Is Overcome 

The Office Action stated that Lazaridis-Shachar-Shiigi disclose imposing file access restrictions 
on said attachment copy [Shiigi, file attachment, col 7 lines 1-col 8 line 30] 

Misunderstood Reference. The Shiigi citation "file attachment" refers to the GIF file of 
handwriting drawing being sent to a recipient as an email file attachment. Sending a GIF 
file (whether the image is of handwriting or not) as an email attachment is well known in 
the art. Nowhere in the cited reference is any restriction on the image file or attachment 
mentioned. It would not make sense to impose such a restriction, since the point of the 
invention is to grant access (get the image to the email f s recipient), and not to restrict 
access to the GIF file. 
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The Rejections of Claim 139, 140 Are Overcome 

The Office Action stated that Lazaridis-Shachar-Shiigi disclose setting a variable level of file 
access restrictions based upon a security level associated with the recipient, whereby attachment 
access can be varied according to the trust placed in a particular recipient individual as 
represented by said security level [Shiigi, authenticate, password, col 8 lines 35-67]. 

The Shiigi citation refers to a user sending an image of handwriting to another user in an 
Instant Messaging mode. Authenticating the user refers to simply confirming that the 
sending user is a valid (registered) user [Shiigi, when the client logs onto the server, the 
server looks up the user name and password in order to authenticate that person as a 
registered user, col 8 lines 42-45]. This is normal primary user authentication to decide 
whether to grant access to the server application (Instant Messaging Java Handwriting 
Server), which is well known in the art. 

However, what is claimed is assigning a security level to a user over and above the mere 
verification that a user is valid. There is no suggestion in Shiigi that this be done. There 
would be no reason to do this, since Shiigi does not discuss file security. 

The Rejection of Claim 143 Is Overcome 

The Office Action stated that claim 143 contains similar limitations set forth in claim 136, and so 
was rejected for the same rationale set forth in claim 136. 

Novelty. Claim 136 has been clearly shown to be patentable under USC 102 and 103 as 
detailed above under the remarks for claim 136. Therefore, Applicant respectfully 
submits that claim 143 is in an allowable form for similar reasons. 

No suggestion to combine references. As detailed above for claim 136, all the 
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references mentioned by the O.A. teach oppositely to the meaning that the O.A. states 
they have. However, even if the meaning was as the O.A. states, there is no suggestion 
that they be combined as the O.A. suggests. 

Valuable, new, improved, and unexpected results. The ability to create an AppLink to 
a computer "GUI Desktop" which is running on a remote application server allows that 
desktop to be used as a Web Portal Home Page, as shown in Figure 33. This "GUI 
Desktop" could preferably include one of the open source Gnome or KDE desktops for 
Linux, since the required code is open to public access and free of charge, or one of the 
Microsoft Windows desktops (win 95, 98, Me, 2000, etc). 

Personalized "home" pages as generated by major web portals such as Yahoo™ have 
evolved over time to contain various features, including personalized news, weather, 
stock quotes, email, an instant messenger application, calendars, and file storage . These 
functions, although generally well designed, are limited by the functionality of the 
various web page languages such as HTML and JavaScript. If an entire web page refresh 
is not to occur every time a viewer initiates an action, JavaScript or it's equivalent must 
be written into the page itself to anticipate such an action and have instructions for 
generating a response. It is impossible to write into a web page with Javascript the full 
functionality of a standard software application. Therefore, these web page functions are 
limited in functionality and poorly performing compared to native software applications. 
Also, generally a web page is a static thing, with the content unchanging until a user 
initiates a web page "refresh". With a (probably password-protected) AppLink to a 
computer's "GUI Desktop" work area, all of these limitations can be overcome. 
Applications can be fully-fledged programs, such as the Microsoft Outlook™ email 
program, rather than glorified web-based forms. Current events can be streamed to the 
user real-time by the program without refresh. Plus the Desktop can run major 
applications which have no HTML equivalent. The desktop can be customized by the 
user to a far greater extent than can the HTML version 
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The Rejections of Claims 144, 146, 148 Are Overcome 

The Office Action stated that Lazaridis-Shachar-Shiigi disclose (a) providing application 
hyperlink generation means on said computer server system for creating said application 
hyperlink; and (b) providing application hyperlink transmission means for transmitting said 
application hyperlink to said at least one recipient user, whereby a wide variety of potentially 
anonymous users are provided simple and easy access to said server-based communications 
applications delivered via thin client, irrespective of the operating system and the overall 
capabilities of the recipients computer, and allowing effortless access to virtually any 
communications application to be placed anywhere a hyperlink can be placed, such as an email 
or web page [Lazaridis, palm top computer, col 6 lines 31-48]. 

Physical Difference- Lazaridis Does Not Teach Operating A Thin Client of Any Type 

In the O.A., operating a thin client of the terminal emulation type on the local computer (i.e. a 
palm computer), is considered equivalent to Lazaridis, palm top computer, seamless, transparent 
redirection of user-selected data items, col 6 lines 31-48. 

While a palm top computer is capable of operating as a dedicated terminal or a software-enabled 
terminal emulator, as is well known in the art, Lazaridis does not refer to a palm top computer 
with either of these capabilities. A palm top computer by itself is not a terminal or terminal 
emulator. It must purposefully be designed for that function or have the necessary software 
purposefully installed. The Lazaridis citation referred to by the O.A. refers to forwarding data to 
the local device (such as a palm top computer) for opening by an application running ON THE 
PALM TOP. This is completely opposite to the accepted meaning of the term "thin client", 
which refers to an application running on a device REMOTE from the user, and the interface to 
that application being delivered to the user via a separate thin client. Lazaridis teaches that the 
application which displays the file runs locally, so there is NO NEED for a thin client. 
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No suggestion to combine references. As detailed above, all the references mentioned 
by the O.A. teach oppositely to the meaning that the O.A. states they have. However, 
even if the meaning was as the O.A. states, there is no suggestion within any of the 
references that they be combined as the O.A. suggests. 

Valuable, new, improved, and unexpected results- Claim 146: The combination of 
said hyperlink with thin-client delivered communications applications results in 
surprising and valuable capabilities, to wit: 

The Sender has a communications program (second communications means). It is not 
necessarily server-based. Most likely it will operate on the sender's PC. It could be any 
type of communications program, for example Instant Messaging. The Sender doesn't 
know, especially with anonymous third parties, whether those potential recipients have a 
compatible Instant Messaging program. However, by sending access to a server-based 
Instant Messaging communications program (first communications means) which IS 
compatible with the Sender's I.M. program, the sender can be assured that the recipient 
can communicate with him. Also, the server-based I.M. program can be preconfigured to 
have the SENDER'S address to facilitate the use of that program to communicate with 
him. 

In this invention, the server-based application is one or more communications programs, 
such as an e-mail, Instant Messaging, Chat (IRC), Voice Chat (Voice Over Internet 
Protocol), or Video Chat application or executable. The communications program may 
preferably be preconfigured with the communications address of the sender. The 
Communications AppLink can then be used by the AppLink recipient to communicate 
with the sender, who will have a compatible communications program, either server- 
based, or locally installed. This "CommLink" could be sent along with an AppLink to 
another file that the sender wishes to collaborate with the recipient about, or have the 
recipient view and discuss. Using AppLink, access to one user's communication tools 
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could be sent to another user via server-based communications programs in a web page or 
e-mail. Suitable applications may include Instant Messaging, as in Figure 19b, email, or 
voice over IP and video conferencing in those instances in which the local client program 
can access the relevant components of the local machine, such as the microphone or 
WebCam. Figure23 is a depiction of a screen view for an alternate implementation of a 
communication link according to an embodiment of the present invention. The recipient 
could communicate with the sender despite having no compatible communications 
programs installed on his local machine. This would allow guaranteed reliable 
communication with any number of recipients in a manner fully supported by both/all 
users, with no problems with incompatible or conflicting proprietary communications 
applications or executables. The communications applications could be configured, 
according to the desires of the sender, to allow the recipient to only communicate with 
the sender, for example according to the sender's addresses already set up in the 
application. 



The Rejection of Claim 145 Is Overcome 

The Office Action stated that Lazaridis-Shachar-Shiigi disclose a first communications means 
consisting of a communications program or application [Shiigi, java applet, col 4 lines 43-63; col 
5 line 34-col 6 line 67; col 7 lines 1-67]. 

Physical difference. The Shiigi citation is for a drawing and optionally an email client 
java applet which is downloaded to the client PC, and operates there. In contrast, the 
communications means mentioned in the claim operates on the server, and is explicitly 
delivered via thin client. As discussed above under remarks for numerous claims, 
Simonoff s meaning of thin client is different from the meaning as defined in the current 
application's specifications as essentially a terminal emulation-type thin client. 
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No suggestion to combine references. As detailed above, all the references mentioned 
by the O.A. do not teach the meaning that the O.A. states they have. However, even if the 
meaning was as the O.A. states, there is no suggestion that they be combined as the O.A. 
suggests. 

Valuable, new, improved, and unexpected results. Please see remarks for claims 144, 
146, and 148 for details of the valuable and unexpected results which also flow from 
claim 145. 

The Rejections of Claims 147, 149, 170, 184 Are Overcome 

The Office Action stated that Lazaridis-Shachar-Shiigi disclose said first and second 
communications means comprises programs selected from the group consisting of: (a) an email 
program (b) an instant messaging program; (c) a voice-over-internet-protocol 

Misunderstood references. A description of how the Lazaridis-Shachar-Shiigi citations 
are physically different than the claimed invention are detailed above for claim 136. Also 
included for that claim are reasons why the combination of Lazaridis-Shachar-Shiigi are 
not operative. The suggested combination is not suggested in the references. 

Claim 147 is simply a reification of claim 146, and clears the requirements of USC 102 
and 103 for the reasons detailed for claim 146. 

Claim 149 is dependent upon a hyperlinked-to computer GUI desktop (claim 148) , and is 
a reification of that claim. Therefore it clears the requirements of USC 102 and 103 for 
the reasons detailed for claim 148. 

Claim 170 is dependent on claim 153, and is simply a reification of that claim, and clears 
the requirements of USC 102 and 103 for the reasons detailed for claim 153. 
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Claim 184 is dependent on claim 183, and is simply a reification of that claim, and clears 
the requirements of USC 102 and 103 for the reasons detailed for claim 183. 

No suggestion to combine references. As detailed above, all the references mentioned 
by the O.A. do not teach the meaning that the O.A. states they have. However, even if the 
meaning was as the O.A. states, there is no suggestion in the references themselves that 
they be combined as the O.A. suggests, and the abundant valuable, new, and 
unexpected results (as detailed above for numerous claims) show that this combination 
is non-obvious. 



The Rejection of Claim 150 Is Overcome 

The Office Action stated that Lazaridis-Shachar-Shiigi disclose providing access to said 
computer visual interface desktop to subscribers of said commercial service, whereby said 
application hyperlink recipient may utilize said visual interface desktop in a manner similar to 
accessing a personalized home web page which utilizes HTML or javascript code, but with the 
full functionality of standard software applications instead of the limited functionality of said 
HTML or javascript code [Shiigi, col 4 lines 43-63; col 5 line 34-col 6 line 67; col 7 lines 1-65]. 

Physical difference. Claim 150 is the invention of claim 148 used in a commercial 
service. Claim 150 is dependent on claim 148, which in turn is dependent on claim 143. 
For the reasons detailed in those claims, claim 150 is novel and results in valuable, new, 
and unexpected results. These results show that this combination is non-obvious when 
used as a commercial service. 

Neither Lazaridis, Shachar nor Shiigi use a thin client as the term is defined in the claim. 
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The first Shiigi citation refers to a java applet email client, and a java application version 
of an instant messaging client. Both are communications programs that run locally, unlike 
the claimed invention [Shiigi, there are two versions of the Handwriting Messaging 
Client software described below, i.e., a Java applet and a Java application version, col 4 
lines 51-54]. The second Shiigi citation refers to a server component for handwriting 
recognition and its functioning with the client drawing and messaging software 
mentioned in the previous citation. There is no suggestion in Shiigi of providing a remote 
computer visual interface desktop to users. Likewise, as detailed in claim 132, Simonoff 
does not disclose a terminal-emulation thin client. In any case, neither reference teaches 
any element of the claim:a commercial service of access to thin client-delivered server 
applications having GUIs by activating a hyperlink. 

No suggestion to combine references. As detailed above, all the references mentioned 
by the O.A. do not teach the meaning that the O.A. states they have. However, even if the 
meaning was as the O.A. states, there is no suggestion in the references themselves that 
they be combined as the O.A. suggests. 



The Rejection of Claim 165 Is Overcome 

The Office Action stated that Lazaridis-Shachar-Shiigi disclose said file restriction means are 
varied depending upon parameters of said specific session selected from the group consisting of: 
(a) the identity of said hyperlink recipient user; (b) the network address of said hyperlink 
recipient user; (c) whether a qualifying action has been performed by said recipient user; and (d) 
whether authentication information has been provided by said hyperlink recipient user [Shiigi, 
authenticate, col 8 lines 35-67]. 

Reification of Claim 161. Claim 165 is dependent upon claim 161, and is a reification 
and narrowing of that claim. It clears the requirements of USC 102 and 103 for the 
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reasons detailed under remarks for claim 161. 

Claim 201 Added to Clarify What Is Claimed. Claim 201 has been added which 
simply claims variable file restrictions. It clarifies that file restrictions are not limited to 
the list in claim 165. It is dependent on claim 161. 

The Rejection of Claim 166 Is Overcome 

The Office Action stated that Lazaridis-Shachar-Shiigi disclose said authentication information 
is selected from the group consisting of: (a) a password; (b) the network address of said 
hyperlink recipient user; (c) a digital signature, and (d) information provided via the HTTP 
authentication protocol [Shiigi, authenticate, password, col 8 lines 35-67]. 

Claim 166 is a reification of claim 165's term "authentication information". It clears the 
requirements of USC 102 and 103 for the reasons detailed under remarks for claim 165. 

Shiigi Authentication Refers to I.M. Account Login. The complete Shiigi citation 
makes clear that he is referring to a server verifying that a user is a registered user of an 
Instant Messaging application, which cannot function without broadcasting the 
immediate availability online of participants: [Shiigi, when the client logs onto the server, 
the server looks up the user name and password in order to authenticate that person as a 
registered user, then the user is added to the list of active users, col 8 lines 42-45]. The 
complete citation makes clear that the authentication Shiigi is referring to is requested in 
order to allow a named user access to his own application account. There is no suggestion 
that anyone other than the name on the user account would be granted access to the 
application and any stored files. 

Novelty. In contrast, in claim 166, the authentication information claimed is not used to 
allow a known user to access his server account. Rather, it is used in a computer 
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algorithm to decide whether to grant a potentially large number of persons access to a 
particular file and online application, less like logging on to a user f s own online account, 
and more like restricting access to a web site to particular persons, which is well known 
in the art. What is not known is the combination of such authentication with hyperlink 
access to online thin-client delivered applications and associated files. 

Valuable, new, improved, and unexpected results. Employing the novel file restriction 
means of claim 161 in conjunction with information gleaned from or about a hyperlink 
activator results in unexpected results for collaboration and LP. protection. The AppLink 
sender or creator has the ability to set and change conditions associated with an 
AppLinked file (for example, file access and usage permissions), or any other variable 
(for example, the degree to which the AppLink usage will be monitored), for example, to 
facilitate protection of the AppLink creator's intellectual property (the AppLinked file). 
This ability to attach various conditions or enable various features for AppLinks is a 
central advantage that AppLinking has over other file transmission and access systems. 
The settable variables may depend on other criteria as well, by which any Settable 
AppLink Variable may be set and varied, for example, according to the specific identity 
of the recipient or the nature of the file, or whether the recipient is a member of a specific 
group of users, the recipient's location or country, as identified by his IP address, or any 
other relevant criteria. 

The Rejection of Claim 183 Is Overcome 

The Office Action stated that Simonoff-Shiigi disclose notifying at least one designated user 
upon the occurrence of hyperlink access events selected from the group consisting of (a) 
hyperlink activation; (b) file access; and (c) file alteration [Shiigi, notify to client, col 8 lines 16- 
30], 

Claim Rewritten and Divided Into Two. The claim 183 has been rewritten to claim 
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basic notification upon hyperlink access events, and claim 202, dependent upon claim 
1 83, has been added, reifying the hyperlink access events with the above list of a-c. 

Claim 183 now reads: The method of claim 151, further comprising the step of notifying 
at least one designated user who is not said least one remote recipient user upon the 
occurrence of hyperlink access events. 

Claim 202 reads: The method of claim 183, wherein said hyperlink access events are 
selected from the group consisting of: 

(a) hyperlink activation; 

(b) file access; and 

(c) file alteration. 

No suggestion to combine references. As detailed above, all the references mentioned 
by the O.A. do not teach the meaning that the O.A. states they have. However, even if the 
meaning was as the O.A. states, there is no suggestion in the references themselves that 
they be combined as the O.A. suggests. 

Shiigi Citation Misinterpreted- Physical Difference With Claimed Invention. The 

Shiigi citation is to notify a recipient that he has received a message in real time, similar 
to Instant Messaging mode. Note that the notification is to the receiver, not the sender. 
[Shiigi, the receiving Handwriting Java Client is notified when an email message to the 
Real Time Jave Server, and retrieves the email message from the server. In this way, 
communications can take place using the Handwriting Java Client in near real time, col 8 
lines 23-28] Words to clarify that the notification goes to a person other than the receiver 
have been added to the claim. 

Shiigi functions oppositely to claimed invention. If notification about hyperlink access 
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were sent to the person doing the accessing, it would have no useful purpose, since that 
person already knows he is accessing the hyperlink. 

Valuable, new, improved, and unexpected results. This difference is significant and 
nonobvious, because the result is to inform or notify the sender or a member of his 
collaborative group of the accessing or alteration of an applinked file, in order, for 
example, to allow said user to approve or disapprove of the changes. Or, for example, a 
salesperson could be notified that an applink to a sales quotation has been accessed. This 
potentially real-time notification, and the knowledge that a prospect has read the quote, 
would obviously be of value if, for example, the salesperson were just about to visit the 
sales target. These unexpected results indicate that the novel structure of this claim is 
non-obvious. 

The Rejection of Claim 185 Is Overcome 

■ The Office Action stated that Lazaridis-Shachar-Shiigi disclose said notification includes details 
about said hyperlink access events [Shiigi, notify to client, col 8 lines 16-30]. 

This claim is a reification and narrowing of claim 183. Please see remarks for that claim 
for discussion of how the citation is misinterpreted and reasons that this is claim is novel 
and unobvious (clears USC 102 and 103). 

The Rejection of Claim 186 Is Overcome 

The Office Action stated that Lazaridis-Shachar-Shiigi disclose said details about said hyperlink 
access events comprises data selected from the group consisting of (a) details about said recipient 
user; (b) the time of activation of said application file hyperlink; (c) information about said file 
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associated with said application file hyperlink; (d) the network location of said hyperlink 
recipient user; (e) information about any changes to said data file [Shiigi, notify to client, col 8 
lines 16-30]. 

This claim is a reification of claim 185's term "details about said hyperlink access 
events". Please see remarks for that claim for discussion of how the citation is 
misinterpreted and reasons that this is claim is novel and unobvious (clears USC 102 and 
103). 



The Rejection of Claim 196 Is Overcome 

The Office Action stated that Lazaridis-Shachar-Shiigi disclose (g) forwarding said incoming 
email without the attached file to the intended member user f s email account; and (h) said member 
user accessing said attached data file by activating said application file hyperlink [Shiigi, 
recipient's Email box, col 7 lines 67; web page col 7 line 54], 

Incorrect Claim Referred to By O-A. The actual text of claim 196 reads: 

Claim 196. The method of claim 151, wherein said means for selecting said file-compatible 
application is adapted to make said selection after considering criteria selected from the group 
consisting of: 

(a) information about optimum applications for viewing of said file; 

(b) information about optimum applications for manipulation of said file; 

(c) said recipient user's legal rights to use available file-compatible applications; and 

(d) usage permissions associated with said available file-compatible applications. 
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Non-Relevant Citation. Claim 196 does not mention email. Rather, it is a dependent 
claim of claim 151, which is an independent claim for the basic application-file hyperlink 
(applink) method. Claim 196 is a reification of claim 151*s term "selecting said file- 
compatible application". 

Novelty. Claim 196 is novel for reasons detailed above under claim 151. 

Valuable, new, improved, and unexpected results. The use of an algorithm to select 
which thin-client delivered application should be used to open a file is nonobvious. A 
software algorithm may be implemented to select the appropriate application to open a 
file within an AppLink, based on appropriate criteria, which could include but is not 
limited to: recipient ownership of application user rights to possible application choices; 
any license agreements for possible application choices including but not limited to end- 
user agreements and service provider agreements; and application file compatibility, or 
which file types possible application choices can open. When an AppLink is sent to a 
recipient, the selection of the server-based application to open the file depends on server- 
based application software license terms. Many end-user software license agreements 
contain the limitation that it cannot be used by more than one person at a time, thus losing 
potential sales. If a user sends an AppLink which requires an application which has such 
a license, one way to comply with that license provision is to ensure that the recipient has 
the right to use that application also. Before the application is presented to the recipient, 
if the algorithm had access to an AppLink recipient application rights database, as 
depicted in Figure 18, it could be verified that the recipient owns or is renting the 
application or otherwise has rights to use the application. If the recipient did not have 
rights to use that application, the AppLink application selection algorithm could search 
for another application which had terms that allow that user to use the application. Such 
terms could include applications licensed by the application service provider on a "per 
seat" basis, that is, not assigning rights to individual users, but, for example, to a 
maximum number of simultaneous users, whose identity could change. The terms might 
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include free "demo" licensing for AppLink recipients. Another type of application which 
might be considered by the algorithm could be an "Open Source" application which 
typically has a license permitting unrestricted use. 

The algorithm could also consider other applications for which the recipient has rights, 
and which are compatible with the file being AppLinked, but not necessarily the 
application used by the AppLink sender to create the file ("native application"). As a 
lower priority, a compatible "viewer" application with appropriate licensing could be 
selected, with the limitation that the user may not be able to interact with the file to the 
degree that he could if a fully capable native file application were used. This 
embodiment of the present invention, by which licensing impacts application 
functionality, may be implemented in conjunction with a previously-discussed 
embodiment, by which various application versions have different functionality in order 
to effect file permission security. That is, licensing terms may give differing levels of 
functionality for different payments to the vendor or different circumstances. A 
"demonstration" license might require disabled functionality. 

As an example, illustrative in that many possible file access avenues are explored, 
assume that a user "Joe" has created a flowchart with the Microsoft® Visio® for 
Windows® application. He creates an AppLink to the file and sends it to recipient 
"Larry". The selection algorithm would first see if Larry is on file with an Application 
License Tracking Database that the algorithm has access to. If Larry is found, the 
algorithm looks to see if he has rights to Visio, the application used to create the file. In 
the event that he does not, the algorithm looks to see if the Visio software vendor is 
perhaps allowing AppLink to be used to non-owners as a marketing mechanism. If the 
Visio vendor is not, the algorithm then looks for other applications that Larry owns or has 
rights to which are capable of opening the file. In the event that he has none, the 
algorithm then looks at applications that the application service provider has licensed on 
a per-seat basis that are file-compatible. If the ASP has none, the algorithm then looks at 
open source programs that the ASP has available to it to see if any are file-compatible. If 
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none are, the algorithm then looks to see if the ASP has any less-capable "viewer"-type 
applications with appropriate licenses that could be used to at least display the file to the 
recipient. In the event that the ASP does have such a viewer, the algorithm selects it and 
the AppLink Server presents the file to Larry inside the viewer. As a further 
implementation of this license tracking function, a database may be provided for use by 
an AppLink Recipient Application Selection Algorithm as described above, which 
contains the software applications and license terms that an AppLink recipient has rights 
to. An AppLink Recipient Application Selection Algorithm according to the present 
invention could function without knowledge of the application rights of AppLink 
Recipients, but access to such a database would improve the performance of such an 
algorithm by increasing the number and quality of the choices available to it, ensuring 
that the optimal legal application is used for file access. 



The Rejection of Claim 197 Is Overcome 



The Office Action stated that Lazaridis-Shachar-Shiigi disclose (a) the provision of valuable 
consideration by said recipient user in exchange for rights to use available file-compatible 
application; (b) the provision by said recipient user of information authenticating the recipient 
user's legal rights to use available file-compatible applications {Shiigi, authenticate, col 8 lines 
40-45]; and (c) the subscription by said recipient user to rights to use said available file- 
compatible application [Shachar, permit access, col 8 lines 5-16]. 

Shiigi Authentication Refers to LM. Account Login. The complete Shiigi citation 
makes clear that he is referring to a server verifying that a user is a registered user of an 
Instant Messaging application, which cannot function without broadcasting the 
immediate availability online of participants: [Shiigi, when the client logs onto the server, 
the server looks up the user name and password in order to authenticate that person as a 
registered user, then the user is added to the list of active users, col 8 lines 42-45]. The 
complete citation makes clear that the authentication Shiigi is referring to is requested in 
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order to allow a named user access to his own application account. There is no suggestion 
that anyone other than the name on the user account would be granted access to the 
application and any stored files. 

Physical Difference. The full Shachar citation is: "The data communications network 
122 permits access to one or more service providers 124". There is no discussion of 
variable access to and manipulation of computer files via remote thin-client delivered 
applications, as claimed. Rather, the Shachar prior art refers to accessing various HTML- 
based services and the related web pages. Nowhere does Lazaridis-Shachar-Shiigi discuss 
file access restrictions. Because Shachar does not contemplate using server-based 
applications as a means of hyperlink-enabled broad communication, they do not disclose 
ways to restrict or modify such communication. 

Reification of Claim 196. Claim 197 is a reification of claim 196's term "legal rights". It 
clears USC 102 and 103 for reasons detailed above for claim 196. 

No suggestion to combine references. As detailed above, all the references mentioned 
by the O.A. do not teach the meaning that the O.A. states they have. However, even if the 
meaning was as the O.A. states, there is no suggestion in the references themselves that 
they be combined as the O.A. suggests. 

Novelty. In contrast, in claim 197, the authentication information claimed is not used to 
allow a known user to access his server account. Rather, it is used in a computer 
algorithm to decide whether to grant a potentially large number of persons access to a 
particular file and online application, less like logging on to a user's own online account, 
and more like restricting access to a web site to particular persons, which is well known 
in the art. What is not known is the combination of such authentication with hyperlink 
access to online thin-client delivered applications and associated files. 

Valuable, new, improved, and unexpected results. Employing the novel file restriction 
means of claim 196 in conjunction with information gleaned from or about a hyperlink 
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activator results in unexpected results for collaboration and LP. protection. The AppLink 
sender or creator has the ability to set and change conditions associated with an 
AppLinked file (for example, file access and usage permissions), or any other variable 
(for example, the degree to which the AppLink usage will be monitored), for example, to 
facilitate protection of the AppLink creator's intellectual property (the AppLinked file). 
This ability to attach various conditions or enable various features for AppLinks is a 
central advantage that AppLinking has over other file transmission and access systems. 
The settable variables may depend on other criteria as well, by which any Settable 
AppLink Variable may be set and varied, for example, according to the specific identity 
of the recipient or the nature of the file, or whether the recipient is a member of a specific 
group of users, the recipient's location or country, as identified by his IP address, or any 
other relevant criteria. 



The Rejection of Claim 198 Is Overcome 



The Office Action stated that Lazaridis-Shachar-Shiigi disclose (a) providing a user group 
comprising at least one member user with access to an email account [Shiigi, recipient's 
email box, col 7 lines 67; web page col 7 lines 54]. 

Email Accounts Well-known in Art, Claimed Combination is Not. Shiigi does refer to 
a user having an email account. This is well-known in the art. What is claimed, however, 
is a user with an email account in combination with the email gateway server, which 
intercepts emails before they get to a recipient and replaces the attachment with an 
AppLink. 

Valuable, new, improved, and unexpected results. A server screens all incoming e- 
mails for attachments. If an e-mail has an attached file, this file is removed from the e- 
mail and stored on the server after being scanned for viruses. An AppLink to the file is 
created and the AppLink is appended to the e-mail.The e-mail is then forwarded to its 
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intended recipient, who opens the attachment via the AppLink, thus eliminating the 
danger of computer viruses for the recipient's computer. 

Acute, unmet need. Computer viruses propagated by email attachments, as is well 
known, cause billions of dollars of damage annually. 

The Rejection of Claim 199 Is Overcome 

The Office Action stated that claim 199 had similar limitations to claim 198, and was rejected for 
the same rationale. 

Please see the remarks for claim 198, above. Claim 199 clears the requirements of USC 
102 and 103 for the reasons detailed under remarks for claim 198. 

Novelty. Claim 199 addresses a completely different need and functions differently from 
the invention of claim 198. In a related embodiment to claim 198, but for a contrasting 
purpose, outgoing e-mail can be treated similarly, by removing and storing the 
attachments, and creating an AppLink which is added to the e-mail instead. 

Valuable, new, improved, and unexpected results. For outgoing e-mails, the 
replacement of all attachments with AppLinks may aid in the control of a company's 
intellectual property, by ensuring that the attached files remain with the company, and 
AppLink recipient file permissions or properties may be restricted centrally according to 
company policy and the recipient permissions in general. 



The Rejection of Claim 200 Is Overcome 
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The Office Action stated that Lazaridis-Shachar-Shiigi disclose centrally setting parameters of 
the file access and manipulation restrictions for said user group. . .as inherent features of 
manipulate the authentication [Shiigi, manipulate, col 2 lines 52-64]. 

The citation from Shiigi does not refer to authentication. However, the full citation makes clear 
that his meaning of the word "manipulate" is related to applications that are completely resident 
upon the client PC [Shiigi, . . .a drawing editor/viewer that allows the user to compose, 
manipulate, and view handwritten or handdrawn messages, col 2 lines 58-60]. Shiigi does not 
mention authentication in this section because there would be no reason to authenticate a user on 
his own PC to use his own applications or access his own files. Further, there is no suggestion in 
Shiigi or Lazaridis or Shachar that thin client applications be used to deliver access to files. 

New, Unexpected, and Valuable Results. Claim 200 is dependent on claim 199, which claims a 
gateway for outbound emails. The establishing and setting of security levels adds surprising 
results to the invention of claim 199. For outgoing e-mails, the replacement of all attachments 
with AppLinks may aid in the control of a company's intellectual property, by ensuring that the 
attached files remain with the company, and AppLink recipient file permissions or properties 
may be restricted centrally according to company policy and the recipient permissions in general. 

The Rejection of Claims 164, 167-169 Are Overcome 

Claims 164, 167-169 were rejected as obvious over Lazaridis et al [Lazaridis, 6,219,694] in view 
of Felciano et al [Felciano 6,052,730] 

The Rejection of Claim 164 Is Overcome 

The Office Action stated that Lazaridis discloses said file access and manipulation restrictions 
(i.e.: permission) are selected from the set consisting of (f) whether said data file or portions 
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thereof may be copied onto the local computer memory clipboard of the remote recipient user 
computing device. 

However, the Office Action stated that Lazaridis does not detail: 

(a) whether the data file may be accessed; 

(b) a number of times the data file may be accessed [Felciano, tracking access, col 2 lines 20-48]; 

Non-Relevant Reference. This Felciano citation addresses tracking a user's activity, not 
the claimed limiting of that activity. 

(c) a particular time period during which the file may be accessed [Felciano, perform periodic 
web searches, col 7 lines 43-67]; 

Misunderstood Reference. Felciano teaches automatically performing web searches 
periodically after a user session based on information gleaned from that user session, in 
hopes of finding something the user will be interested in. It does not refer to restricting 
the time of a user session. 

(d) whether said hyperlink recipient user may print (i.e.: view) the data file locally [Felciano, 
viewing the page, col 5 lines 35-42]; 

Physical Difference, Felciano teaches downloading a tracking applet which monitors 
activities while a user is viewing a page (things like mouse cursor movement, etc.). This 
applet has no effect on the user f s access to a page or to what he can do with the web page 
data. It is simply a monitoring (spyware) program. In contrast, the claimed invention is 
for limiting access to a server-based file, not monitoring that access. 

(e) whether said hyperlink recipient user may save said first data file locally onto said remote 
recipient user computing device [Felciano, storing and tracking, col 4 lines 37-65]; 
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Physical Difference. The Felciano citation teaches a method for tracking various data 
about a user's web sessions. In contrast, the claimed invention is for limiting access to a 
server-based file, not monitoring that access. 

(f) whether said data file or portions thereof may be copied onto the local computer memory 
clipboard of the remote recipient user computing device; 

(g) whether, after alteration by said recipient user, said data file or portions thereof may be saved 
onto said computer server system, whereby the original copy of said data file is replaced by the 
altered file, and said application file hyperlink is now associated with said altered file, and (h) 
whether, after alteration by said recipient user, said data file or portions thereof may be saved 
onto said computer server system, whereby the original copy of said data file is not replaced by 
the altered file and remains on the storage system of said server system [Felciano, permits task to 
be performed, original file or URL, modified URL, col 4 lines 21-35]. 

Fundamentally, there is no suggestion in Felciano of a recipient user altering anything, 
unlike what is claimed. The citation "permits tasks to be performed" refers to tasks 
accomplished by the program/server, not the user. 

The O.A. states that it was well known that Internet information can be monitored (i.e.: 
customer, visitor hits) or print or stored on local memory (i.e.: saving downloaded file) or edit 
file by resipient as taught by Felciano [Felciano, perform periodic web searches, col 7 lines 43- 
67; viewing the page, col 5 lines 35-42; storing and tracking, col 4 lines 37-65; permits task to be 
performed, original file or URL, modified URL, col 4 lines 21-35]. Therefore it would have been 
obvious to an ordinary skill in the art to incorporate the technique of modifying web session as 
taught by Felciano into Lazaridis's apparatus in order to utilize the applet. Doing so would 
provide the Web client a dynamic tool to modify hypertext browsing activities. 

Felciano does not refer anywhere to a user editing a file. The citation "perform periodic 
web searches" refers to automatically performing web searches periodically after a user 
session based on information gleaned from that user session, in hopes of finding 
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something the user will be interested in. It does not refer to restricting the time of a user 
session, "storing and tracking" teaches a method for tracking various data about a user's 
web sessions. In contrast, the claimed invention is for limiting access to a server-based 
file, not monitoring that access, "permits task to be performed" refers to tasks 
accomplished by the program/server, not the user. Fundamentally, there is no suggestion 
in Felciano of a recipient user altering anything, unlike what is claimed. 

Felciano explicitly discloses that his invention cannot monitor application usage, unlike 
the claimed invention [Felciano, Lamprey cannot tack subsequent interactions with the 
FTP service. . .This limitation is due to the fact that the client browser is now interacting 
through the FTP protocol and not the HTTP protocol, col 6 lines 47-49]. For the same 
reasons, Felciano cannot track or monitor application usage in the claimed invention, 
which uses the thin client protocol, not HTTP. 

Also, as mentioned above under the remarks for claim 132, neither Lazaridis nor Shachar 
nor Felciano teach a thin client as claimed. 

The Rejections of Claims 167-169 Are Overcome 

The Office Action stated that Lazaridis-Felciano discloses said qualifying action is accepting an 
agreement; said agreement obligates the recipient user to limit disclosure of the content of said 
data file; said agreement is a license agreement {Felciano, a simple rule, col 4 lines 1-8]. 

Incorrect Reference. The citation does not contain the words "a simple rule". 

Reification of claim 166. Claims 167-169 are dependent upon claim 166 and reifications 
of that claim. They meet the requirements of USC 102 and 103 for reasons detailed under 
the remarks for that claim. 
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Concluding Remarks 

Commercial Success. Applicant has achieved commercial success that flows from the functions 
and advantages disclosed in the specification. A declaration thereto with supporting documents 
was attached to the previous amendment B. The Examiner is invited to peruse the Applicant's 
company's web site, www.marix.com, which details commercial implementations of the claimed 
inventions. 

From MPEP 716.03(b): In ex parte proceedings before the Patent and Trademark Office, an 
applicant must show that the claimed features were responsible for the commercial success of an 
article if the evidence of nonobviousness is to be accorded substantial weight. 

Applicant has implemented the claimed invention in hardware and software. Applicant has 
achieved commercial success by selling the invention to numerous customers as laid out in the 
declaration attached to the previous Amendment. 

Nexus Between the Claimed Invention and Evidence of Commercial Success. The 

commercial success achieved is directly attributable to the claimed invention. This is clearly 
shown by the fact that the commercial product as sold uses a separate product to carry out the 
web-enablement of the server-based applications, i.e., the Tarantella web-enabling program (an 
equivalent to Citrix). That is, it is an add-on package which adds AppLink capability to the 
functionality of the basic web-enabling package. There would be no reason to purchase it if the 
customer did not want the additional functionality. 

Example: One customer, an auto dealership, uses AppLink to deliver price quotes to potential 
customers while retaining the quotes on its server to prevent the customer from simply taking the 
quote to another dealer to get a better price. 
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Example: The US Air Force Academy bought the claimed invention to distribute extremely 
sensitive information to its teachers. Specifically, there is a list of potentially suicidal students 
that is distributed to the teachers so that they can "go easy" on those students. This list was 
inadvertently emailed to local news organizations. The sender realized her error immediately, but 
the information was irretrevably on its way. With AppLink, the URL can be inactivated at any 
time, and further is always linked to the most current document. 

Commercial Acquiescence. Applicant has demonstrated commercial acquiescence by licensing 
the present invention's technology to Tarantella, a division of Sun Microsystems, as laid out in 
the declaration with supporting documents attached to the previous Amendment B. 

Invention Has Been Examined Previously by the USPTO. This invention was submitted as an 
international patent application (International PCT Application No. PCT/00/24719, System and 
Method of Permissive Data Flow, filed September 8, 2000), which contained claims broader than 
the ones in the present application. This application was examined by Examiner James R. 
Matthews as the US agent of the PCT. In an International Preliminary Examination dated 
October 3, 2002. Almost every claim was found to be patentable by Examiner Matthews. 

Invitation To Try a Commercial Model of the Invention. The Examiner is invited to try out 
the claimed invention from the comfort of his workplace or home. Actually trying the invention 
briefly can quickly illustrate its novel features and advantages. The Applicant has created a web 
site with numerous example AppLinks which are hosted on the Applicant's company servers. 
The web site is: http://applinks.blogspot.com. Please note the client PC requirements as detailed 
on the web page. Please feel free to call the Applicant at any time for assistance, if needed, at 
612 963-8233. The Applicant will know within seconds when the Examiner has accessed the 
hyperlinks because an email with access details is automatically sent to the hyperlink originator, 
as claimed for the present invention. Also, the Examiner is invited to try an AppLink creation 
account, wherein the Examiner can upload his own documents to the AppLink server and create 
his own AppLinks. Also, the Examiner is invited to try out an account on the Applicant's 
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company's demo AppLink Email Gateway Server which screens incoming emails and substitutes 
an AppLink for any attached files. 

For all of the above reasons, applicant submits that the specification and claims are now in 
proper form and that the claims all define patentability over the prior art. Therefore applicant 
submits that this application is now in condition for allowance, which action he respectfully 
solicits. 

If the application is not believed to be in full condition for allowance, applicant respectfully 
requests assistance and suggestions of the Examiner. 

Very respectfully, 



James L. Rice 
Applicant Pro Se 

2115PennAveS. 
Minneapolis, MN 55405 
Tel 612 963-8233 

Certificate of mailing: I certify that this correspondence, and attachments, if any, will be 
deposited with the United States Postal Service by First Class Mail, postage prepaid, in an 
envelope addressed to "Box Non-Fee Amendments, Commissioner for Patents, P.O. Box 1450, 
Alexandria, VA 22313-1450" on the date below. 
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